Am Dienstag, den 05.02.2019, 19:04 +0100 schrieb Miro Hrončok: > 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
Hi Miro,
I've hust checked the examples you haven given here, and none of them
require nor link any symbol from glibc:
$ nm -Dg --with-symbol-versions _contextvars.cpython-37m-x86_64-linux-
gnu.so
w __cxa_finalize
w __gmon_start__
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U PyContext_CopyCurrent
U PyContextToken_Type
U PyContext_Type
U PyContextVar_Type
00000000000011a0 T PyInit__contextvars
U PyModule_AddObject
U PyModule_Create2
So in this case you don't need to worry or fix something, as those name
Python modules are dlopen()'en from somewhere in the Python executable
and do not call any glibc function directly.
Note: Even the weak `__cxa_finalize` dtor-function is not needed by the
code from this module as it doesn't do any (static) stack allocations
that need cleanup when unloading the module.
Anyways, if you get a line saying `${name}@GLIBC_2.*` from a library /
module after running the command above *in combination* with such an
error from rpmlint, something is broken.
Cheers,
Björn
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
