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}(a)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