* 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
