I have a similar problem with the proposed package pveclib. I my case I have a data only libraries. I can eliminate the rpmlint error by forcing a link to -lc But I am not sure the the appropriate solution.
---------- Forwarded message ----------
From: Florian Weimer <fweimer@xxxxxxxxxx>
To: "Miro Hrončok" <mhroncok@xxxxxxxxxx>
Cc: devel@xxxxxxxxxxxxxxxxxxxxxxx, Marcel Plch <mplch@xxxxxxxxxx>
Bcc:
Date: Mon, 08 Jul 2019 15:25:27 +0200
Subject: Re: rpmlint: shared-lib-without-dependency-information (parts of Python stdlib)
* Miro Hrončok:
> On 05. 02. 19 19:04, Miro Hrončok wrote:
>> I've just spotted these when working on Python 3.8.0a1. This happens
>> on 3.7 as well since GCC 9:
>>
>> python3-debug.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37dm-x86_64-linux-gnu.so
>> python3-debug.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37dm-x86_64-linux-gnu.so
>>
>> python3-libs.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37m-x86_64-linux-gnu.so
>> python3-test.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37m-x86_64-linux-gnu.so
>>
>>
>> (Note that there are plenty of other extension modules that do not
>> raise this error.)
>>
>> This doesn't happen with latest python3 built prior to the gcc update to 9.
>>
>> $ rpmlint -I library-not-linked-against-libc
>> library-not-linked-against-libc:
>>
>> That isn't helpful either.
>>
>> I found a similar Debian thing [1] that says:
>>
>> > It is theoretically possible to have a library which doesn't use any symbols
>> > from libc...
>>
>> Do I care? Should I fix something? I honestly have no idea.
>>
>> [1] https://lintian.debian.org/tags/library-not-linked-against-libc.html
>
>
> We have new errors on F30+:
>
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_contextvars.cpython-38-x86_64-linux-gnu.so
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_heapq.cpython-38-x86_64-linux-gnu.so
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_testimportmultiple.cpython-38-x86_64-linux-gnu.so
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_testinternalcapi.cpython-38-x86_64-linux-gnu.so
>
> rpmlint doesn't give much info:
> $ rpmlint -I shared-lib-without-dependency-information
> shared-lib-without-dependency-information:
>
>
> But lintian again explains the issue:
> https://lintian.debian.org/tags/shared-lib-without-dependency-information.html
>
> The listed shared library doesn't include information about which
> other libraries the library was linked against. (When running "ldd
> foo.so" ldd should report about these other libraries. In your case,
> ldd just reports "statically linked".)
>
> I again think this is OK for Python extension modules.
> Thoughts?
It depends on the extension module. For _contextvars, it's okay because
it does not link against anything (glibc or otherwise). Global C++
destructors will not work because of unfulfilled weak reference to
__cxa_finalize, but you probably do not care about that.
rpmlint really should have a list of symbols from system libraries that
need linking, otherwise there's always going to be false positives for
such plugins. (Although extension modules could link against libpython
on Fedora because Fedora doesn't use the fat Python interpreter, unlike
some other distributions.)
Thanks,
Florian
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
