From szhang31415 at gmail.com Wed Jan 27 13:09:09 2021 From: szhang31415 at gmail.com (Simon Zhang) Date: Wed, 27 Jan 2021 13:09:09 -0500 Subject: [Wheel-builders] build a multilinux wheel for cuda project Message-ID: Hi, I am trying to build a multilinux wheel for a cuda project. see: https://stackoverflow.com/questions/42585210/extending-setuptools-extension-to-use-cmake-in-setup-py and: https://packaging.python.org/tutorials/packaging-projects/ and: https://github.com/pypa/auditwheel 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. [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. 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. Please help!! Thanks, Simon Zhang -------------- next part -------------- An HTML attachment was scrubbed... URL: From ehashman at debian.org Sat Jan 30 00:03:37 2021 From: ehashman at debian.org (Elana Hashman) Date: Fri, 29 Jan 2021 21:03:37 -0800 Subject: [Wheel-builders] build a multilinux wheel for cuda project In-Reply-To: References: Message-ID: <0cf30a441c3f49ca98389e04d1d6699c@debian.org> 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 From szhang31415 at gmail.com Sun Jan 31 12:43:50 2021 From: szhang31415 at gmail.com (Simon Zhang) Date: Sun, 31 Jan 2021 12:43:50 -0500 Subject: [Wheel-builders] build a multilinux wheel for cuda project In-Reply-To: <0cf30a441c3f49ca98389e04d1d6699c@debian.org> References: <0cf30a441c3f49ca98389e04d1d6699c@debian.org> Message-ID: Hi Elana, so your suggestion of using manylinux2014 allows me to auditwheel repair the linux wheel file without complaints. I'm not sure I understand the subsequent process I need to do with PyPI. If I copy the manylinux2014 wheel back to my local machine (into the dist folder) and run the command: python3 -m twine upload --repository testpypi dist/* following the instructions from: https://packaging.python.org/tutorials/packaging-projects/ when I pip3 install spamplusplus (this is the name I gave my test project) https://test.pypi.org/project/spamplusplus/ I get that the CMakeLists.txt file is not existent. I used the same setup.py file given in the link: https://stackoverflow.com/questions/42585210/extending-setuptools-extension-to-use-cmake-in-setup-py However I get the error that CMakeLists.txt file is not being uploaded? cmake /tmp/pip-build-6ff9ifuu/spamplusplus -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=/tmp/pip-build-6ff9ifuu/spamplusplus/build/lib.linux-x86_64-3.6/spamplusplus -DCMAKE_BUILD_TYPE=Release CMake Error: The source directory "/tmp/pip-build-6ff9ifuu/spamplusplus" does not appear to contain CMakeLists.txt. If you don't know how to answer my question(s) could you redirect me to a Python (PyPI) expert who can help me? Thanks, Simon Zhang On Sat, Jan 30, 2021 at 12:03 AM Elana Hashman wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: