[Wheel-builders] Trouble building manylinux2014 wheel

[Daniel Alley]

On a semi-unrelated note, I'm also interested in packaging libmodulemd
itself, which is (as I mentioned) a gobject-based library.  Is it possible
to make that packaged in a self-contained way, without having a ton of
system dependencies?

On Tue, Feb 18, 2020 at 12:06 PM Daniel Alley <dalley at redhat.com> wrote:

> Filed here: https://github.com/pypa/auditwheel/issues/229
>
> On Tue, Feb 18, 2020 at 11:45 AM Nathaniel Smith <njs at pobox.com> 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 <dalley at 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 <dalley at 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 <njs at pobox.com> wrote:
>>>>
>>>>> On Tue, Feb 18, 2020 at 6:08 AM Daniel Alley <dalley at 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
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/wheel-builders/attachments/20200218/feaf9365/attachment.html>