Provide docker images based on more recent operating systems

[cwiede]

Hi,

I'm not sure whether this issue has been brought up before, I tried to search but didn't find a lot.

As a background, I'm trying to port my project depending on PySide2 to PySide6 (i.e., from Qt5 to Qt6). This project also uses shiboken for creating some C extensions. The minimal supported host operating systems for Qt6 are these (see https://www.qt.io/blog/qt6-development-hosts-and-targets):

• Ubuntu 20.04 (64bit Intel; gcc9)
• CentOS 8.1 (64bit Intel; gcc9)
• SLES 15 (SUSE Linux Enterprise Server, 64bit Intel; gcc10)
• Open SUSE 15.1 (64bit; gcc9)

None of these seem to be supported by any available manylinux docker image. I understand that manylinux tries to use old operating systems for backward compatibility reasons. However, this makes it impossible to build proper extension modules for libraries requiring more recent dependencies, which is a pity. I was hoping that the situation gets better with PEP600, but actually it got worse (see #1012). Wouldn't it make sense to have docker images available for more recent dependencies?

As kind of a consequence, all qt related extensions seem to ignore the manylinux standard completely. All packages PyQt5, PyQt6, PySide2 and PySide6 (mis-)use manylinux1.

[henryiii]

Currently, manylinux1 (centOS 5) has gcc 4.8 (C++11), manylinux2010 (centOS 6) has gcc 8 (C++17), manylinux2014 (centOS 7) has gcc 10 (C++17), and manylinux_2_24 (Debian 9) has gcc 6 (C++14). Due to the loss of CentOS LTS releases, manylinux_2_24 uses Debian, so it does not have access to the RedHat Developer Toolkit, which backported modified GCC versions to older glibc. But for now, manylinux2014 should cover all the use cases listed above.

The main reason that users lie about manylinux compatibility is not because 2010 or 2014 does not work for them, but it's because pip versions that are still common on system package managers (pip 9 on CentOS 7 & 8) are too old to load anything but manylinux1. So adding newer manylinux_2_x wouldn't help them, and they would still do what they do today. Old versions of pip need to go away before they will use the tools we build.

manylinux_2_24 is already very new - the best course of action would likely be to recreate the same trickery used by RedHat's developer toolkit to allow newer GCC versions to link only using older GCC version symbols - sort of a partial static/dynamic link.

Also, you can always fully statically link a library, in which case you have a larger binary, but you don't depend on the libstdc++ version on the machine - are you sure that's not what Qt bindings are doing?

[cwiede]

Thanks for taking a look.

I understand that there is a second reason for lying about manylinux compatibility, but at least for Qt6 projects this might not be the main reason.

But for now, manylinux2014 should cover all the use cases listed above.

No, it doesn't. Even though the compiler would be sufficient to compile the c++-17 project, the Qt6 dll's are still incompatible to manylinux2014 (and also to manylinux_2_24, but here also the compiler is not sufficient). I'm not exactly sure if debian10 would be sufficient for Qt6 (glibc seems to be 2_28 which is also used in centos 8.1), I'm sure that debian11 is.

Qt6 projects do not compile on manylinux2014 due to glibc incompatibility to the shared objects shipped with PySide6 / Qt6, which are exactly the binaries provided by the Qt company.

The compatibility decision of the Qt company might be questionable, but it is not something I have in my hands and it is probably not something which will be withdrawn. Would the correct way to go forward in these cases be using debian10/debian11 and tagging the wheels with manylinux_2_28/manylinux _2_31? Aside from not profiting from the manylinux docker images, would I be able to upload such wheels to pypi?

Re-Building QT is definitely not an option because PySide6 already uses the standard qt libraries.

[mayeut]

auditwheel says that PyQt6 is manylinux_2_24compatible (which does not mean you could be able to build it with that image).
For PySide6, it's manylinux_2_28 compatible.

Let's try working something out for manylinux_2_28 images.
There are already relevant discussion about this in #1012 and https://discuss.python.org/t/using-ubi7-images-instead-on-centos7-for-future-manylinux-images/1709/24
This will probably require some work in auditwheel as well if the GLIBCXX_3.4.25 symbol version causes too much problems.
If that's the case package, maintainers will be able to opt-out of supporting distributions without this symbol (the only one being known at the moment being PhotonOS 3).

[mayeut]

@cwiede,

would you mind trying the mayeut/manylinux:manylinux_2_28_x86_64 image to see if that's working for you ?

[mayeut]

@cwiede,

I'm closing this issue as being superseded by #1282, can you report there if that's working for your use-case ?
Thanks