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.
see https://bugzilla.redhat.com/show_bug.cgi?id=1725924
---------- Forwarded message ---------- From: Florian Weimer fweimer@redhat.com To: "Miro Hrončok" mhroncok@redhat.com Cc: devel@lists.fedoraproject.org, Marcel Plch mplch@redhat.com 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.ht...
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