We are doing nonstandard stuff with our headers, so SDL assumed that
both iconv and dlopen are available inside LibC, which they aren't.
Fix that by adding a dependency on libiconv and adding additional
linker flags.
Some applications search for the external version of libtic and
libtinfo, which are no longer present after
91ad7754fe.
Having a symlink fixes that, since libncurses exports the necessary
functions if they aren't available as a seperate library.
The xmlrpc.client module has some trial-and-error logic at module import
time to figure out how to properly format years using strftime. There
have already been problems in the past with this code in Python (see
https://bugs.python.org/issue13305, which is still open), and Serenity
only adds to that.
This problem has been reported at https://bugs.python.org/issue45386, so
hopefully in time we won't need this patch anymore.
Compiling against an OpenSSL thread-enabled shared library (see #10207)
lets Python compile its _ssl module, which yields an importable ssl
module.
The ssl module suffers from the same problem described in #10014 though,
namely that python crashes when importing different modules results in
multiple libcrypto.so loads, and its functions are later invoked by one
of the modules. Once #10277 is merged though the module becomes quite
usable.
By defining our own target platform in the OpenSSL compilation
configuration we can now compile an OpenSSL shared library. We need to
avoid symbol versioning though, as serenity's LibELF doesn't support
this yet.
We are now also compiling with threading support to allow using this
from Python.
We may need entries with spaces in makeopts, installopts, and
configopts, and at that point we should also convert depends and
auth_opts to avoid confusion.
This is too much bash magic for a simple "Use this value if the script
doesn't set anything", especially since only one default setting depends
on values from the script.
I used "git grep -FIn http://" to find all occurrences, and looked at
each one. If an occurrence was really just a link, and if a https
version exists, and if our Browser can access it at least as well as the
http version, then I changed the occurrence to https.
I'm happy to report that I didn't run into a single site where Browser
can't deal with the https version.
In commit ba97548686 `--with-termlib` was added to produce a
`libtinfo.a` file that nano then required. However, this causes ncurses
to build with _only_ screen-pointer ext funcs: e.g.
`reset_prog_mode_sp` exists, but `reset_prog_mode` does not.
By switching to `--enable-term-driver`, all functions are properly
exported again and the nano port compiles and runs just fine. :^)
Now that we're generating the CMake toolchain file in the build
directory, we need to redirect the ports that use CMake to the new
location. Looking into this showed that there's still a bunch of work to
do in general to make the ports agnostic to which toolchain they're
using, there's a lot of hard-coded ${ARCH}-pc-serenity-gcc assumptions
still here.
