Repairwheel: how to identify which symbol(s) are too recent

Hi,
I have packaged a large C++ project using PySide2. I already succeeded in the past but I have updated gcc and clang to recent versions. I have built everything from source in manylinux_2_24 containers. But now I get

#25 45.55 auditwheel: error: cannot repair "/lima-python/dist/aymara-0.4.0-cp37-cp37m-linux_x86_64.whl" 
to "manylinux_2_24_x86_64" ABI because of the presence of too-recent versioned symbols.
 You'll need to compile the wheel on an older toolchain.

I suppose a let something contaminate my toolchain but I cannot see what.

Is there a way to let auditwheel trace what it does to identify precisely the source of the problem?

I suppose auditwheel show should do the job but I don’t understand how to interpret its result:

#25 [21/32] RUN auditwheel show /lima-python/dist/aymara-0.4.0-cp37-cp37m-linux_x86_64.whl
#25 sha256:bff2e56b10f90f854633820861dfb933e56983f132d8823fbc406279dc65314a
#25 45.23 
#25 45.23 aymara-0.4.0-cp37-cp37m-linux_x86_64.whl is consistent with the
#25 45.23 following platform tag: "linux_x86_64".
#25 45.23 
#25 45.23 The wheel references external versioned symbols in these
#25 45.23 system-provided shared libraries: libgcc_s.so.1 with versions
#25 45.23 {'GCC_3.4', 'GCC_3.0', 'GCC_4.0.0'}, libdl.so.2 with versions
#25 45.23 {'GLIBC_2.2.5'}, libm.so.6 with versions {'GLIBC_2.23',
#25 45.23 'GLIBC_2.2.5'}, libc.so.6 with versions {'GLIBC_2.9', 'GLIBC_2.2.5',
#25 45.23 'GLIBC_2.7', 'GLIBC_2.15', 'GLIBC_2.14', 'GLIBC_2.10', 'GLIBC_2.17',
#25 45.23 'GLIBC_2.3', 'GLIBC_2.8', 'GLIBC_2.3.2', 'GLIBC_2.11', 'GLIBC_2.3.4',
#25 45.23 'GLIBC_2.6', 'GLIBC_2.16', 'GLIBC_2.4'}, libstdc++.so.6 with versions
#25 45.23 {'GLIBCXX_3.4.18', 'CXXABI_1.3.3', 'CXXABI_1.3', 'CXXABI_1.3.2',
#25 45.23 'CXXABI_1.3.7', 'GLIBCXX_3.4.28', 'GLIBCXX_3.4', 'GLIBCXX_3.4.17',
#25 45.23 'GLIBCXX_3.4.26', 'GLIBCXX_3.4.22', 'CXXABI_1.3.5', 'GLIBCXX_3.4.9',
#25 45.23 'CXXABI_1.3.1', 'GLIBCXX_3.4.19', 'CXXABI_1.3.8', 'CXXABI_1.3.9',
#25 45.23 'GLIBCXX_3.4.14', 'GLIBCXX_3.4.20', 'GLIBCXX_3.4.11',
#25 45.23 'GLIBCXX_3.4.15', 'GLIBCXX_3.4.21'}, libpthread.so.0 with versions
#25 45.23 {'GLIBC_2.3.3', 'GLIBC_2.2.5', 'GLIBC_2.12', 'GLIBC_2.3.2',
#25 45.23 'GLIBC_2.3.4'}, libpng16.so.16 with versions {'PNG16_0'},
#25 45.23 libQt5Core.so.5 with versions {'Qt_5_PRIVATE_API', 'Qt_5', 'Qt_5.15'},
#25 45.23 libQt5Network.so.5 with versions {'Qt_5'}, libQt5Qml.so.5 with
#25 45.23 versions {'Qt_5', 'Qt_5_PRIVATE_API'}, libQt5QmlModels.so.5 with
#25 45.23 versions {'Qt_5_PRIVATE_API'}, libQt5Gui.so.5 with versions {'Qt_5',
#25 45.23 'Qt_5_PRIVATE_API'}, libQt5Quick.so.5 with versions {'Qt_5'},
#25 45.23 libQt5Widgets.so.5 with versions {'Qt_5'}, libQt5Test.so.5 with
#25 45.23 versions {'Qt_5', 'Qt_5_PRIVATE_API'}, libbsd.so.0 with versions
#25 45.23 {'LIBBSD_0.2'}, librt.so.1 with versions {'GLIBC_2.2.5'}, libz.so.1
#25 45.23 with versions {'ZLIB_1.2.3.4'}, libgomp.so.1 with versions {'OMP_1.0',
#25 45.23 'GOMP_4.0'}

This seems like a good feature request to make to auditwheel, to mention the “too recent” symbols that it found in the wheel.

:point_up: @mayeut see above

Continuing my research, I found the tool auditwheel-symbols in this SO question which does the job.

But I also figured out that all my work here was based on a wrong assumption: I thought that by compiling gcc 10 on a manylinux_2_24, I could then use it to generate manylinux_2_24 compatible wheels but reading this issue, I understand that I was plainly wrong and that I have no solution except to switch to manylinux_2_28 because I need a recent clang to build PySide and thus I need a somewhat recent (c++17) gcc to build a recent clang.

Can you confirm this?

Yes, that sounds right; the work to integrate devtoolset patches and be able to use a more recent GCC version on manylinux_2_24 was not done.

Note that mainly for this reason, manylinux_2_24 is now obsolete/EOL (see DISCUSS: manylinux_2_24 EOL? · Issue #1332 · pypa/manylinux · GitHub), so I’d suggest to simply switch to manylinux_2_28 and your problem will be solved.

Thanks. Yes, it seems that most necessary tools are available in 2_28. But I have no (recent) experience with rpm-based distros and I was hoping to be able to still use a deb-based one.
I have also complex dependencies like tensorflow1.9 that will be complicated to compile there.

But hey, let’s learn new things…

And, to close the loop: Describe which symbols are too recent · Issue #36 · pypa/auditwheel · GitHub exists.

2 Likes