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 <[email protected]> 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@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@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 >
_______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
