[Wheel-builders] build a multilinux wheel for cuda project

[Elana Hashman]

On 2021-01-27 10:09, Simon Zhang wrote:

> I tried running audit wheel from the docker image:
> 
> $ docker run -i -t -v `pwd`:/io quay.io/pypa/manylinux1_x86_64 
> /bin/bash
> 
> however get the same error message:
> 
> [root at dd2c9c25006a cmake_cuda_test]# auditwheel show 
> dist/spam_plusplus-0.1-cp38-cp38-linux_x86_64.whl
> 
> spam_plusplus-0.1-cp38-cp38-linux_x86_64.whl is consistent with the
> following platform tag: "manylinux2014_x86_64".
> 
> The wheel references external versioned symbols in these system-
> provided shared libraries: libdl.so.2 with versions {'GLIBC_2.2.5'},
> librt.so.1 with versions {'GLIBC_2.2.5'}, libpthread.so.0 with
> versions {'GLIBC_2.3.2', 'GLIBC_2.2.5'}, libc.so.6 with versions
> {'GLIBC_2.14', 'GLIBC_2.3.3', 'GLIBC_2.3', 'GLIBC_2.17',
> 'GLIBC_2.2.5'}
> 
> This constrains the platform tag to "manylinux2014_x86_64". In order
> to achieve a more compatible tag, you would need to recompile a new
> wheel from source on a system with earlier versions of these
> libraries, such as a recent manylinux image.

This is not really an "error", per se, but an analysis that your 
compiled wheel is using symbol versions from libc that are too new for 
the older manylinux tags.

manylinux2014 should still provide plenty of compatibility. I know there 
is a new format that is not calendar-based but I'm not sure what the 
state of support is in auditwheel as I no longer maintain it.

> [root at dd2c9c25006a cmake_cuda_test]# auditwheel repair 
> dist/spam_plusplus-0.1-cp38-cp38-linux_x86_64.whl
> INFO:auditwheel.main_repair:Repairing 
> spam_plusplus-0.1-cp38-cp38-linux_x86_64.whl
> usage: auditwheel [-h] [-V] [-v] command ...
> auditwheel: error: cannot repair 
> "dist/spam_plusplus-0.1-cp38-cp38-linux_x86_64.whl" to 
> "manylinux2010_x86_64" ABI because of the presence of too-recent 
> versioned symbols. You'll need to compile the wheel on an older 
> toolchain.

Auditwheel fixes wheels by vendoring any external shared objects they 
rely on. But in this case, your wheel doesn't rely on external .so's; 
the compatibility issue is that it was compiled with too new a version 
of gcc for a manylinux2010 tag.

This constrains the systems it would be compatible with, but you still 
have a perfectly serviceable manylinux wheel.

> How do I compile on the manylinux image on docker?
> 
> I cannot even get python3 to work on the docker image nor the command 
> "locate" to find python3.

The manylinux1 docker image is long out of security support. I would not 
recommend using it. There are manylinux2010 and 2014 docker images also 
available. The documentation is all available here: 
https://github.com/pypa/manylinux#manylinux2010

> Please help!!

A more recent maintainer might also want to chime in.

- e