Closed
Conversation
* pypy3-exe requires a few patches to build properly on musl based
systems. This should solve the build problems once python2_7 is
fixed on the host system.
Collaborator
|
pushed. |
|
Please make sure you use repoman to prevent errors from creeping into the overlay. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pypy3 musl compatibilty patches
When trying to install pypy3, the default dependency calculation will opt to
use 'pypy' to build pypy3, it's the recommended way of building pypy3 by
upstream, because pypy can compile pypy3 much faster than CPython can:
However, dev-python/pypy pulls in a dependency on dev-python/pypy-exe-bin (as
the base 'pypy' package needs to be compiled somehow), which unfortunately is
linked against glibc. Attempting to run that binary gives the all familiar
'file not found' when it fails to find musl's dynamic loader.
#Possible approaches
Provide a musl dev-python/pypy-exe-bin
This would involve creating a dev-python/pypy-exe-bin on a musl system
(presumably by bootstrapping with CPython), and handwaving about how to resolve
the musl version of the package against the glibc version of the bin package.
Bootstrap pypy3 with CPython instead
Gentoo/musl already has a working CPython interpreter. So bootstrapping pypy3
with CPython shouldn't be difficult, it just takes longer. All that is required
to force the dev-python/pypy3 ebuild to use CPython is to add the following to
/etc/portage/package.mask:
Great it's pulling in python 2.7 for bootstrapping.
Fixing the build
Attempting to build the package leads to three compilation failures. The first
is a known issue, and has a PR open in upstream CPython with a fix:
python/cpython#18380
Failing to patch dev-lang/python2_7 with the above will cause the build of
dev-python/pypy3-exe to complain about being unable to detect the system libc.
The other two failures occur when attempting to compile dev-python/pypy3-exe
during the bootstrapping phase and are issues to do with assumptions pypy3 has
made about the system libc which only hold true for glibc based systems.
Missing definition of struct timeval
Several files in the pypy3 codebase refer to struct timeval, in fact
pypy/module/cpyext/include/pytime.h uses a pointer to timeval structs when
defining a bunch of function prototypes, however it neglects to include
<sys/time.h>. This leads to a bunch of warnings:
whereas pypy/module/cpyext/src/pytime.c does include
<sys/time.h>, this leads to conflicting type definitions for the functions
defined in pytime.h (gcc uses
int*to represent the unknown structure ), and thus a compile error:The fix is relatively simple. Patch pytime.h to include <sys/time.h>. Either by
patching pytime.h directly, or by patching Python.h (which is where many of the
c library includes are centralised in pypy's codebase). A diff for the latter
looks like as follows:
Re-definition of
stdoutAt some point during the package build, pypy generates C code from rpython
scripts that re-defines stdout to
extern FILE*:This conflicts with the musl definition in stdio.h of
extern FILE* const,this leads to the following build error:
full build log
Fixing this is similarly trivial, patching
rpython/rlib/rfile.pyto emit thecorrect type does the trick.
With that. The package builds and installs, enough for pypy3 to print hello world.
Hopefully I've added all the required files/information to get this ebuild working, I'll give it another test tonight by attempting to install from this ebuild without patches in my /etc/portage/patches/... and update the PR if necessary.