> > Are you using the manylinux2014 docker images to build your wheels? > That should automatically take care of the C runtime issues and > various other subtle details. It's not technically mandatory, but in > practice basically everyone should be using it. >
I'm using the official docker images from quay.io and the script provided here: https://github.com/pypa/python-manylinux-demo/tree/master/travis Modified as such: #!/bin/bash > set -e -x > > # Install a system package required by our library > yum install -y cmake make bzip2-devel expat-devel file-devel glib2-devel > libcurl-devel libmodulemd2-devel libxml2-devel openssl-devel sqlite-devel > zchunk-devel zlib-devel xz-devel rpm-devel > > # Compile wheels > for PYBIN in /opt/python/*/bin; do > "${PYBIN}/pip" install -r /io/requirements-dev.txt > "${PYBIN}/pip" wheel /io/ -w wheelhouse/ > done > > # Bundle external shared libraries into the wheels > for whl in wheelhouse/*.whl; do > auditwheel show "$whl" > auditwheel repair "$whl" --plat $PLAT -w /io/wheelhouse/ > done > > # Install packages and test > for PYBIN in /opt/python/*/bin/; do > "${PYBIN}/pip" install createrepo_c --no-index -f /io/wheelhouse > (cd "$HOME"; "${PYBIN}/nosetests" createrepo_c) > done > I suppose it's worth mentioning that libmodulemd2 is a gobject-based library, do you think that might present problems? On Tue, Feb 18, 2020 at 8:37 AM Nathaniel Smith <n...@pobox.com> wrote: > On Tue, Feb 18, 2020 at 5:19 AM Daniel Alley <dal...@redhat.com> wrote: > > > > Hi all, > > > > I am attempting to package a C library with python extensions, > createrepo_c, as a Python wheel that we can distribute on PyPI. The > library compiles successfully on every platform we've tried, but > "auditwheel repair" fails with the error: > > > >> auditwheel: error: cannot repair > "wheelhouse/createrepo_c-0.15.7-cp35-cp35m-linux_x86_64.whl" to > "manylinux2014_x86_64" ABI because of the presence of too-recent versioned > symbols. You'll need to compile the wheel on an older toolchain. > > > > > > Here is the output of "auditwheel show" and "auditwheel repair": > https://pastebin.com/zBA2KGqV > > > > I *think* (but don't know for sure) that the problem is that installing > the development headers for libcurl forces new versions of curl and libcurl > to be installed. But I'm not that experienced at this and the tooling > doesn't explicitly say which symbols are "too recent". > > > > https://pastebin.com/raw/1uDxrwXx > > > > Here is the full code -- see the branch referred to by this PR: > https://github.com/rpm-software-management/createrepo_c/pull/207 > > > > Can anybody point me in the right direction towards resolving this > issue? Is this a bug, a problem with my own code, a problem with the RPMs > available? > > I don't think libcurl is involved – 'auditwheel repair' will vendor > libcurl. The libraries it can't vendor are the C runtime libraries > like libc, libm, libgcc_s. (I agree that it'd be nice if auditwheel > gave more details!) > > Are you using the manylinux2014 docker images to build your wheels? > That should automatically take care of the C runtime issues and > various other subtle details. It's not technically mandatory, but in > practice basically everyone should be using it. > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > >
_______________________________________________ Wheel-builders mailing list Wheel-builders@python.org https://mail.python.org/mailman/listinfo/wheel-builders