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.
When building a port as a dependency for another port the HOST_*
variables were previously initialized with values referring to the
SerenityOS toolchain.
Fixes#9168.
Previously, libcurl is not used in the git build because the test
program in configure fails to link against it properly. We bypass the
test and make sure we link against all necessary libraries (libssl,
libcrypto and zlib).