Describe which symbols are too recent

[takluyver]

Using the manylinux docker image, I get this error message:

auditwheel: error: cannot repair "wheelhouse/pygame-1.9.2.dev1-cp34-cp34m-linux_x86_64.whl" to "manylinux1_x86_64" ABI because of the presence of too-recent versioned symbols. You'll need to compile the wheel on an older toolchain.

It would be helpful to know which symbols it doesn't like!

[takluyver]

In this case it seems to have been caused by leftover config from one Python build to the next, and I have fixed it. But I still think that it would be useful for this error to give more information.

[lelit]

I started to get the mentioned error, only for the Python 3.6 wheel though. Previous builds completed without error, but latest changes to the source (I used a few abstract APIs like PyMapping_Check and PyObject_SetItem...) triggered the problem.

Is there some way to investigate the issue, or any workaround?

[pitrou]

Seconded. I can't understand any of this. For example auditwheel tells me this:

DEBUG:auditwheel.policy.versioned_symbols:Package requires GLIBCXX_3.4.21, incompatible with policy manylinux1_x86_64 which requires {'GLIBCXX_3.4.8', 'GLIBCXX_3.4.6', 'GLIBCXX_3.4.4', 'GLIBCXX_3.4.1', 'GLIBCXX_3.4.7', 'GLIBCXX_3.4.5', 'GLIBCXX_3.4.3', 'GLIBCXX_3.4.2', 'GLIBCXX_3.4'}

But when looking at the detailed log, the only component with that symbol is... libstdc++.so.6.

[abitrolly]

Here is the example of such build.

https://travis-ci.org/mkleehammer/pyodbc/jobs/639016254

[ax3l]

Here is another example on ppc64le (using the quay.io/pypa/manylinux2014_ppc64le build chain and glibc-static version 2.17-292.el7): https://travis-ci.com/github/openPMD/openPMD-api/jobs/319416158

$ sh -c 'auditwheel repair -w /tmp/repaired_wheels "$1"' repair_command /tmp/built_wheel/openPMD_api-0.11.1a0-cp35-cp35m-linux_ppc64le.whl
INFO:auditwheel.main_repair:Repairing openPMD_api-0.11.1a0-cp35-cp35m-linux_ppc64le.whl
usage: auditwheel [-h] [-V] [-v] command ...
auditwheel: error: cannot repair "/tmp/built_wheel/openPMD_api-0.11.1a0-cp35-cp35m-linux_ppc64le.whl"
to "manylinux2014_ppc64le" ABI because of the presence of too-recent versioned symbols.
You'll need to compile the wheel on an older toolchain.

[ax3l]

@mayeut do you have an idea how to fix this? :)

[mayeut]

@ax3l, unfortunately I don't. you can try to run auditwheel show or run in verbose mode to see if this helps.

PR are welcomed for this issue.

[zoj613]

auditwheel: error: cannot repair "dist/pyhtnorm-0.1.0-cp37-cp37m-manylinux2014_x86_64.whl" to "manylinux1_x86_64" ABI because of the presence of too-recent versioned symbols. You'll need to compile the wheel on an older toolchain.

Im also getting this error when using auditwheel on a whl build using poetry for a package that uses GLIBC, BLAS and LAPACK. anyone knows a workaround?

The only way it works is if I add --plat linux_x86_64. The other manylinux versions give an error

[messense]

I've made a tool for this today: https://github.com/messense/auditwheel-symbols

pip install auditwheel-symbols
❯ auditwheel-symbols --manylinux 2014 ~/Downloads/rjieba-0.1.5-cp36-abi3-manylinux2010_x86_64.whl
rjieba/rjieba.abi3.so is manylinux2014 compliant.

❯ auditwheel-symbols --manylinux 1 ~/Downloads/rjieba-0.1.5-cp36-abi3-manylinux2010_x86_64.whl
rjieba/rjieba.abi3.so is not manylinux1 compliant because it links the following forbidden libraries:
libc.so.6   offending symbols:  memcpy@@GLIBC_2.14