Linux builds for release 20231002 are incompatible with gcc

[freakboy3742]

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:

• Flatpak, which only provides gcc in the development sandbox
• Any manylinux build in an environment earlier than manylinux_2_28. manylinux_2014 (which is the next oldest still supported manylinux) only provides clang-5.

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 using gcc for third-party binary module compilation is a supported use case.

[indygreg]

Thanks for the report.

Breaking GCC compatibility was definitely an unintended side-effect with adding -fdebug-default-version.

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.

[ghost]

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

[indygreg]

Yeah, the sed search-and-replace is essentially the type of hack I aim to employ.

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.

[indygreg]

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.

[freakboy3742]

@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.

[indygreg]

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 -fdebug-default-version=4. Now that we opened pandora's box to rewriting the sysconfig data post build, I'm receptive to additional changes to normalize the configurations to maximize distribution portability. (e.g. normalizing CC to cc.) Please file GitHub issues or PRs with suggestions!

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!)