On Tue, Feb 5, 2019 at 8:03 PM Miro HronĨok <mhroncok(a)redhat.com> 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...
lintian bugged me about this on a totally unrelated project, and fwiw
the shared objects in question were dlopen'ed as modules so whether or
not they'd use libc symbols does not matter, they'd get them from the
calling process.
Also in that case, nothing is actively done NOT TO link against libc,
but the following flags were passed to libtool:
-module -export-dynamic -avoid-version -shared
Granted, I didn't check in the libtool documentation whether any of
those imply not linking against libc.
Dridi