Huh. I'm not sure what GLIBC_PRIVATE is, but it doesn't seem like something your wheel *should* be depending on... So either there's something funny about your exact library setup, or there's a bug in how auditwheel is looking up symbol versions. I think at this point I'd file a bug on auditwheel.
On Tue, Feb 18, 2020, 08:40 Daniel Alley <dal...@redhat.com> wrote: > So, I just went through the "auditwheel show" output and compared it > against the manylinux2014 symbol version whitelists from here: > https://github.com/pypa/auditwheel/blob/8b255b5cf09365d2fd4ab770996005df05a62b63/auditwheel/policy/policy.json > > All of the versions listed for GCC and GLIBC are in the whitelist, except > for one which seems out of place. What is GLIB_PRIVATE? > > libc.so.6 with versions {'GLIBC_2.4','GLIBC_2.15', 'GLIBC_2.3.3', >> 'GLIBC_2.8', 'GLIBC_PRIVATE', 'GLIBC_2.7', 'GLIBC_2.14', 'GLIBC_2.3', >> 'GLIBC_2.2.5', 'GLIBC_2.16', 'GLIBC_2.3.2', 'GLIBC_2.17', 'GLIBC_2.3.4', >> 'GLIBC_2.11', 'GLIBC_2.12'}, >> > > Apart from this, I'm not really sure what to be looking for. > > On Tue, Feb 18, 2020 at 10:12 AM Daniel Alley <dal...@redhat.com> wrote: > >> I'm not sure how that can be happening then. I'm using this exact setup >> to build packages for 2 other libraries and both of those packages work >> great -- this is the only one causing issues. It has the most dependencies >> out of the three. >> >> Here's the command I'm using from the host, and you can see from the >> build script that I'm not installing any new compiler. >> >> docker run --rm -e PLAT=manylinux2014_x86_64 -v `pwd`:/io >>> quay.io/pypa/manylinux2014_x86_64 /io/build_wheels.sh >>> >> >> On Tue, Feb 18, 2020 at 9:45 AM Nathaniel Smith <n...@pobox.com> wrote: >> >>> On Tue, Feb 18, 2020 at 6:08 AM Daniel Alley <dal...@redhat.com> wrote: >>> > I suppose it's worth mentioning that libmodulemd2 is a gobject-based >>> library, do you think that might present problems? >>> >>> No. Somehow you're not using the compiler or libc that come inside the >>> docker image. Individual libraries can't cause these kinds of issues. >>> So either you're somehow not using the docker image, or you're somehow >>> replacing the entire OS inside the docker image, or ... I can't think >>> of any other possibilities :-). >>> >>> -n >>> >>> -- >>> Nathaniel J. Smith -- https://vorpus.org >>> >>>
_______________________________________________ Wheel-builders mailing list Wheel-builders@python.org https://mail.python.org/mailman/listinfo/wheel-builders