Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dev-lang/python-3.11.3: fix build on macOS. #29

Closed
wants to merge 1 commit into from

Conversation

biergaizi
Copy link
Contributor

@biergaizi biergaizi commented May 3, 2023

Currently, dev-lang/python-3.11.3 is unbuildable on macOS for two reasons. First, due to a hardcoded dependency sys-apps/util-linux. This commit fixes it by conditionally requiring sys-apps/util-linux only on "kernel_linux".

Another problem is that there exists two "#ifdef" checks for the system calls mkfifoat() and mknodat(), which are not compatible with GCC. Because they're defined using the __builtin_available() function - specific to clang without a fallback for GCC, they're never defined, thus creating the following errors:

./Modules/posixmodule.c:15647:23: error: 'HAVE_MKFIFOAT_RUNTIME'
undeclared (first use in this function); did you mean
'HAVE_MKDIRAT_RUNTIME'?
./Modules/posixmodule.c:15651:22: error: 'HAVE_MKNODAT_RUNTIME'
undeclared (first use in this function); did you mean
'HAVE_MKDIRAT_RUNTIME'?

These two checks were originally introduced to fix the problem that building Python on the macOS 13 SDK but running it on an earlier macOS version would result in a segfault. Since moving Gentoo Prefix in this manner is not supported, as a temporary fix, we simply revert this patch. Since this change only has an effect on macOS, it's safe to apply it without checking whether we're running on Darwin.

Closes: https://bugs.gentoo.org/905618

@thesamesam thesamesam requested a review from grobian May 3, 2023 06:50
@grobian
Copy link
Member

grobian commented May 3, 2023

hmmm, I'll rebuild on 13.3.1, but I'm sure this succeed fine yesterday

@grobian
Copy link
Member

grobian commented May 3, 2023

ok, it still compiles for me

@biergaizi
Copy link
Contributor Author

ok, it still compiles for me

How is it even possible when it has an unsatisfiable dependency sys-apps/util-linux?

@grobian
Copy link
Member

grobian commented May 3, 2023

you can just use ebuild bla.ebuild install, but I fixed the dependency an hour ago or so

@biergaizi
Copy link
Contributor Author

I'm pretty sure that undefined HAVE_MKFIFOAT_RUNTIME and HAVE_MKNODAT_RUNTIME are a real problem, as I can reliably replicate the problem on macOS 13.2 (Darwin 22.3) on ARM64, with both GCC 12.1 and GCC 12.2, and with both unmodified upstream source, and with Portage ebuild. A Python dev has already wrote a patch, which is now waiting to enter the upstream.

I plan to rework on this pull request and update my patch to the upstream version.

arm64-apple-darwin22-gcc  -Wsign-compare -DNDEBUG     -O2 -pipe -march=native -fwrapv -std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden  -I./Include/internal  -I. -I./Include -I/Users/gentoo/gentoo/usr/include/ncursesw/ -I/Users/gentoo/gentoo/usr/include/ncursesw   -DPy_BUILD_CORE_BUILTIN -c ./Modules/_collectionsmodule.c -o Modules/_collectionsmodule.o
./Modules/posixmodule.c: In function 'probe_mkfifoat':
./Modules/posixmodule.c:15647:23: error: 'HAVE_MKFIFOAT_RUNTIME' undeclared (first use in this function); did you mean 'HAVE_MKDIRAT_RUNTIME'?
15647 | PROBE(probe_mkfifoat, HAVE_MKFIFOAT_RUNTIME)
      |                       ^~~~~~~~~~~~~~~~~~~~~
./Modules/posixmodule.c:15611:11: note: in definition of macro 'PROBE'
15611 |       if (test) {        \
      |           ^~~~
./Modules/posixmodule.c: In function 'probe_mknodat':
./Modules/posixmodule.c:15651:22: error: 'HAVE_MKNODAT_RUNTIME' undeclared (first use in this function); did you mean 'HAVE_MKDIRAT_RUNTIME'?
15651 | PROBE(probe_mknodat, HAVE_MKNODAT_RUNTIME)
      |                      ^~~~~~~~~~~~~~~~~~~~
./Modules/posixmodule.c:15611:11: note: in definition of macro 'PROBE'
15611 |       if (test) {        \
      |           ^~~~
make: *** [Makefile:2697: Modules/posixmodule.o] Error 1
make: *** Waiting for unfinished jobs....
 * ERROR: dev-lang/python-3.11.3::gentoo_prefix failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=dev-lang/python-3.11.3::gentoo_prefix'`,
 * the complete build log and the output of `emerge -pqv '=dev-lang/python-3.11.3::gentoo_prefix'`.
 * The complete build log is located at '/Users/gentoo/gentoo/var/tmp/portage/dev-lang/python-3.11.3/temp/build.log'.
 * The ebuild environment file is located at '/Users/gentoo/gentoo/var/tmp/portage/dev-lang/python-3.11.3/temp/environment'.
 * Working directory: '/Users/gentoo/gentoo/var/tmp/portage/dev-lang/python-3.11.3/work/Python-3.11.3'
 * S: '/Users/gentoo/gentoo/var/tmp/portage/dev-lang/python-3.11.3/work/Python-3.11.3'

@grobian
Copy link
Member

grobian commented May 4, 2023

I think the difference is that I use a 12-based prefix on 13 still.

Currently, dev-lang/python-3.11.3 is unbuildable on macOS due to GCC
incompatibility. There exists two "#ifdef" checks for the system calls
mkfifoat() and mknodat(), which are not compatible with GCC. Because
they're defined using the __builtin_available() function - specific to
clang without a fallback for GCC, they're never defined, thus creating
the following errors:

    ./Modules/posixmodule.c:15647:23: error: 'HAVE_MKFIFOAT_RUNTIME'
    undeclared (first use in this function); did you mean
    'HAVE_MKDIRAT_RUNTIME'?
    ./Modules/posixmodule.c:15651:22: error: 'HAVE_MKNODAT_RUNTIME'
    undeclared (first use in this function); did you mean
    'HAVE_MKDIRAT_RUNTIME'?

This bug [1] has already been reported to upstream with a patch [2]
waiting to be merged. This commit applies the upstream patch to add
the missing GCC fallbacks.

[1] python/cpython#104106
[2] python/cpython#104129

Closes: https://bugs.gentoo.org/905618
Signed-off-by: Yifeng Li <[email protected]>
@biergaizi
Copy link
Contributor Author

I think the difference is that I use a 12-based prefix on 13 still.

I've updated the Pull Request with the new official upstream patch, please review the change again.

@biergaizi
Copy link
Contributor Author

I just realized that it has already been included into Gentoo Prefix Python patches-r1, no further change is needed.

@biergaizi biergaizi closed this May 5, 2023
@biergaizi
Copy link
Contributor Author

@grobian I found the patch you've just committed into the Prefix tree is broken, please fix it as soon as possible, see python/cpython#104129 (comment) for more information, thanks.

The broken patch was committed into the Gentoo Prefix tree at 2023-05-04 07:33:30 UTC, meanwhile I already pointed out that the upstream patch is broken to the upstream Python developers at 2023-05-03 22:44:34 UTC, which was then fixed at 2023-05-04 01:17:25 UTC.

It should've been preventable.

@biergaizi biergaizi reopened this May 5, 2023
@gentoo-bot gentoo-bot closed this in 40796bc May 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants