-
-
Notifications
You must be signed in to change notification settings - Fork 122
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
Linux builds for release 20231002 are incompatible with gcc #194
Comments
Thanks for the report. Breaking GCC compatibility was definitely an unintended side-effect with adding That being said, we never really claimed that the built Python distributions have correct sysconfig metadata that is portable across machines. So I could shrug my shoulders here. However, a growing body of people are relying on these distributions and they do want/need extension compilation to just work. So I think we should restore GCC compatibility. There are a handful of issues around the sysconfig metadata being non-portable. I suppose this issue is finally justification for modifying the sysconfig metadata before packaging so the C toolchain config is more portable. |
I found this workaround in the wild: # Remove clang-specific flags from configurations
- sed -e "s/-fdebug-default-version=4//g" support/python/bin/python3-config > /app/bin/python3-config
- sed -e "s/-fdebug-default-version=4//g" support/python/bin/python3.{{ cookiecutter.python_version.split('.')[1] }}-config > /app/bin/python3.{{ cookiecutter.python_version.split('.')[1] }}-config
- sed -e "s/-fdebug-default-version=4//g" support/python/lib/python3.{{ cookiecutter.python_version.split('.')[1] }}/_sysconfigdata__linux_x86_64-linux-gnu.py > /app/lib/python3.{{ cookiecutter.python_version.split('.')[1] }}/_sysconfigdata__linux_x86_64-linux-gnu.py |
Yeah, the In other news, I lost access to my primary development machine while traveling and won't be back home and in a position to perform a release until ~Christmas. So don't expect much movement from me on this project or getting a release out the door any time soon. |
This causes sysconfigdata to report the compiler binary as `cc` instead of `clang`. On machines with only GCC, this has a better chance of finding any available compiler because Linux machines often have a `cc` symlink in PATH pointing to the active compiler for the system. If running in an environment without `cc` in PATH, this change will break building and downstream users will need to export `CC` or otherwise force Python to use an alternative compiler frontend. `musl-clang` and `gcc` are still reported under their original names. `gcc` should be safe to move over to `cc`. But I'm a little concerned about moving `musl-clang` as that might result in mixing musl and GNU toolchains. We can consider these for follow ups. Part of #194.
This commit implements a long desired feature to normalize the build configuration in various distribution files post build but pre packaging. The goal of this general feature is to make distributions highly portable. Before, configurations (which were used to e.g. compile extension modules) referenced build environment paths, like `/tools`. This is not desirable and can confuse downstream users when unexpected settings are used. The impetus for this work is #194. As part of this change we strip the `-fdebug-default-version` argument from `CFLAGS` to restore CFLAGS compatibility with GCC. There's no doubt additional settings that could be normalized. Those can be implemented as follow-ups.
This commit implements a long desired feature to normalize the build configuration in various distribution files post build but pre packaging. The goal of this general feature is to make distributions highly portable. Before, configurations (which were used to e.g. compile extension modules) referenced build environment paths, like `/tools`. This is not desirable and can confuse downstream users when unexpected settings are used. The impetus for this work is #194. As part of this change we strip the `-fdebug-default-version` argument from `CFLAGS` to restore CFLAGS compatibility with GCC. There's no doubt additional settings that could be normalized. Those can be implemented as follow-ups.
This commit implements a long desired feature to normalize the build configuration in various distribution files post build but pre packaging. The goal of this general feature is to make distributions highly portable. Before, configurations (which were used to e.g. compile extension modules) referenced build environment paths, like `/tools`. This is not desirable and can confuse downstream users when unexpected settings are used. The impetus for this work is #194. As part of this change we strip the `-fdebug-default-version` argument from `CFLAGS` to restore CFLAGS compatibility with GCC. There's no doubt additional settings that could be normalized. Those can be implemented as follow-ups.
Release assets containing a fix for this issue are uploading to https://github.com/indygreg/python-build-standalone/releases/tag/20240107. Please test this pre-release. If I hear positive feedback, I'll promote the release. |
@indygreg Thanks for this; our initial testing seems to indicate this pre-release works, and fixes the clang issue we were seeing with the 20231002 release. |
Thank you, @freakboy3742. I've ripped off the pre-release label for release 20240107. Use at your own leisure. And I'm going to close this issue since it was tracking a specific issue with Thanks for the patience with my inability to conduct a timely release after I lost connectivity to my machine halfway around the world. (I need to invest in a KVM!) |
The Linux builds for release 20231002 include the use of the flag
-fdebug-default-version
.This flag is only available on clang-9 or later, which means that the environment providing binary modules must provide a clang, not just gcc - and a relatively recent (post 2019) version of clang at that.
This is problematic for:
It's not explicitly stated in the docs that Python-build-standalone builds should support
gcc
, but there are comments in this document that strongly imply usinggcc
for third-party binary module compilation is a supported use case.The text was updated successfully, but these errors were encountered: