>
> 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

Reply via email to