What glibc to target for Linux?

[brettcannon]

Should we coordinate with Manylinux somehow to figure out how to decide what glibc version to use?

[brettcannon]

https://github.com/pypa/manylinux seems to use https://almalinux.org as the target distribution. Their lifecycle is 5 years which not only covers the lifetime of a Python release (if they align perfectly), but would very likely cover the 2 years of installer support that we currently follow. As well, they have 10 years of security releases, which means if the answer to #5 is to keep the glibc version for the lifetime of a CPython release, there will be an OS out there with a security release that uses that glibc version.

So, for me, it seems reasonable to say either:

• The oldest Alma Linux version that is still receiving active support (i.e. the 5-year support timeline)
• The oldest Alma Linux version that is still getting security releases

[indygreg]

glibc version compatibility is a big decision because CPython doesn't support runtime detection / weak linking of libc symbols on Linux (unlike macOS).

If CPython gains support for this, the core interpreter + extensions can be much more aggressive about adopting newer glibc.

There are still some quirks in here due to how glibc symbol versions works. But there are hacks to compel the linker to reference older symbol versions.

[emmatyping]

I am not totally sold on weak linking against glibc yet, but I think that should probably be a new thread to discuss

I think I'd say the lower bound should be "The oldest Alma Linux version that will continue to get security releases throughout the 2 year period where installers are provided" (which I think is what Brett was saying in the 2nd bullet point but wanted to be clear)

[emmatyping]

To clarify the above, I apologize if I was dismissive of weak linking. If it works out it could be very exciting. I think I mostly wish to be cautious of adopting it since there are quirks, and I expect we will want to make pre-built python a reality before deciding on weak linkage to glibc symbols

[geofft]

Weak linking on glibc is possible but uncommon, and I think it's something which is probably worth avoiding for an official build. But that is something we're exploring in python-build-standalone. I think that's one of the answers to how this project and python-build-standalone differ (#9): we'll be willing to do something technically weirder that we think we can support and deal with the breakage from. Once we gain confidence in it, we can submit that upstream.

One practical form of this might be that this project and python-build-standalone both are built from the same source code, but we enable some more ambitious feature flags that aren't suitable for an official build.

[emmatyping]

Yes, absolutely, I could see weak linking to glibc being an experimental configure flag that PBS enables.

[hugovk]

I think I'd say the lower bound should be "The oldest Alma Linux version that will continue to get security releases throughout the 2 year period where installers are provided" (which I think is what Brett was saying in the 2nd bullet point but wanted to be clear)

To illustrate, AlmaLinux 8 was released on 2021-03-30, is EOL in 2029-03 and would be used for:

• Python 3.15 (released in 2026-10, installers until 2028-10)

AlmaLinux 9 was released on 2022-05-26, is EOL in 2032-05 and would be used for:

• Python 3.16 (released in 2027-10, installers until 2029-10)
• Python 3.17 (released in 2028-10, installers until 2030-10)
• Python 3.18 (released in 2029-10, installers until 2031-10)

AlmaLinux 10 was released on 2025-05-27, is EOL in 2035-05 and would be used for:

• Python 3.19 (released in 2030-10, installers until 2032-10)
• Python 3.20 (released in 2031-10, installers until 2033-10)
• Python 3.21 (released in 2032-10, installers until 2034-10)

gantt
    title AlmaLinux security and Python installers
    dateFormat YYYY-MM-DD
    axisFormat %Y-%m

    section AlmaLinux 8
    AlmaLinux 8                 :alma8, 2021-03-30, 2029-03-31
    Python 3.15                 :py315, 2026-10-01, 2028-10-31

    section AlmaLinux 9
    AlmaLinux 9                 :alma9, 2022-05-26, 2032-05-31
    Python 3.16                 :py316, 2027-10-01, 2029-10-31
    Python 3.17                 :py317, 2028-10-01, 2030-10-31
    Python 3.18                 :py318, 2029-10-01, 2031-10-31

    section AlmaLinux 10
    AlmaLinux 10                :alma10, 2025-05-27, 2035-05-31
    Python 3.19                 :py319, 2030-10-01, 2032-10-31
    Python 3.20                 :py320, 2031-10-01, 2033-10-31
    Python 3.21                 :py321, 2032-10-01, 2034-10-31

Loading

[geofft]

I think it's good to match against a widely-used manylinux baseline, in part because if you're installing packages from PyPI, it's strictly worse to be slightly older or newer than a standard manylinux tag. It's also helpful for end users who are trying to figure out when they need to upgrade a system, or other projects who are trying to figure out what they should compile their own code for: most of them are already looking at the manylinux ecosystem, and so aligning with that is helpful.

FWIW we currently don't name a particular manylinux baseline in python-build-standalone, just a Debian release that we do our build on, and I think we should name a manylinux baseline and actually run auditwheel on our binaries. Concretely this would help us answer the question of whether we can assume that libatomic is on the target system (the answer to which appears to be a little arch-specific); manylinux is already figuring that question out and there's no point in us answering that differently. For this project, it would also let you assume that things like libX11 are on the system if someone wants to use Tkinter.