Following the pattern for qemu, mold, and clang, we should install the
host python required to build the python port into its own install tree
rather than forcing it into the GNU compiler's bindir.
All of these patches did the same thing, which is already in upstream
config.sub.
With this change, we need only add `use_fresh_config_sub=true` to
the package.sh file.
Note that this is not done automatically in case the port has a modified
config.sub file.
The --enable-optimizations flag attempts to enable PGO. Profile-guided
optimization is great in general, but will not work at all when doing a
cross-compile. If there's a more fine-grained flag for generic
optimization levels that doesn't try to do PGO, we should enable that
instead. The flag also enables `-fno-semantic-interposition`, but our
GCC patches enable that by default for -fPIC anyway, so that's not
necessary.
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.
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.
Neither the _curses nor the termios module builds to completion
currently due to some missing functions, but we can let it try
nonetheless - it'll likely get fixed at some point :^)
This is used in the setup.py file when adding include and lib paths to
the list when crosscompiling, if it's not found in any of the checked
environment variables they don't get added.
I have my environment configured to use https://pre-commit.com/.
I guess the scripts were changed recently to lint all ports, and
the python port was barfing on my system because of this bug.
Attempting to import C-extensions (lib-dynload/*.so) currently asserts
in the dynamic loader - let's just build them statically instead for the
time being.
This makes a large number of modules available for use and the port a
lot more functional! :^)
The current version of our Python port (3.6.0) is over four years old by
now and has (or had, I haven't actually tried it in a while) some
limitations - time for an upgrade! The latest Python release is 3.9.1,
so I used that version. It's a from-scratch port, no patches are taken
from the previous port to ensure the smallest possible amount of code is
patched. The BuildPython.sh script is useful so I kept it, with some
tweaks. I added a short document explaining each patch to ease judging
their underlying problem and necessity in the future.
Compared to the old Python port, this one does support both the time
module as well as threading (at least _thread) just fine. Importing
modules written in C (everything in /usr/local/lib/python3.9/lib-dynload)
currently asserts in Serenity's dynamic loader, which is unfortunate but
probably solvable. Possibly related to #4642. I didn't try building
Python statically, which might be one possibility to circumvent this
issue.
I also renamed the directory to just "python3", which is analogous to
the Python 3.x package most Linux distributions provide. That implicitly
means that we likely will not support multiple versions of the Python
port at any given time, but again, neither do many other systems by
default. Recent versions are usually backwards compatible anyway though,
so having the latest shouldn't be a problem.
On the other hand bumping the version should now be be as simple as
updating the variables in version.sh, given that no new patches are
required.
These core modules to currently not build - I chose to ignore that for
now rather than adding more patches to make them work somehow, which
means they're fully unavailable. This should probably be fixed in
Serenity itself.
_ctypes, _decimal, _socket, mmap, resource, termios
These optional modules requiring 3rd-party dependencies do currently not
build (even with depends="ncurses openssl zlib"). Especially the absence
of a readline port makes the REPL a bit painful to use. :^)
_bz2, _curses, _curses_panel, _dbm, _gdbm, _hashlib, _lzma, _sqlite3,
_ssl, _tkinter, _uuid, nis, ossaudiodev, readline, spwd, zlib
I did some work on LibC and LibM beforehand to add at least stubs of
missing required functions, it still encounters an ASSERT_NOT_REACHED()
/ TODO() every now and then, notably frexp() (implementations of that
can be found online easily if you want to get that working right now).
But then again that's our fault and not this port's. :^)
