Filed here: https://github.com/pypa/auditwheel/issues/229
On Tue, Feb 18, 2020 at 11:45 AM Nathaniel Smith <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> On Tue, Feb 18, 2020 at 6:08 AM Daniel Alley <[email protected]> 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 [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
