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 <fwei...@redhat.com> > To: "Miro Hrončok" <mhron...@redhat.com> > Cc: devel@lists.fedoraproject.org, Marcel Plch <mp...@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.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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
