DevHeads.net

rpmlint: library-not-linked-against-libc (parts of Python stdlib, after gcc 9)

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:

Do I care? Should I fix something? I honestly have no idea.

[1] <a href="https://lintian.debian.org/tags/library-not-linked-against-libc.html" title="https://lintian.debian.org/tags/library-not-linked-against-libc.html">https://lintian.debian.org/tags/library-not-linked-against-libc.html</a>

Comments

Re: rpmlint: library-not-linked-against-libc (parts of Python st

By =?UTF-8?B?TWlyb... at 02/05/2019 - 20:28

On 05. 02. 19 19:04, Miro Hrončok wrote:
Thank You Dridi, Björn and Fabio.

Conclusion here is:

Python extension modules don't need to be linked against libc as they are never
actually loaded on their own, but rather from the Python interpreter. The
rpmlint error is false here.

Re: rpmlint: library-not-linked-against-libc (parts of Python st

By Florian Weimer at 02/07/2019 - 13:50

* Miro Hrončok:

That is definitely not true in general. It depends on what the module
does. This can be rather non-obvious stuff, like taking the address of
a local variable and passing that to another function (which isn't
inlined).

Thanks,
Florian

Re: rpmlint: library-not-linked-against-libc (parts of Python st

By Fabio Valentini at 02/05/2019 - 16:15

I've seen this warning for one of my packages too, and thought it possible
to be related to the new --as-needed linker flag in rawhide.

Fabio

Re: rpmlint: library-not-linked-against-libc (parts of Python st

By =?UTF-8?Q?Bj=c3... at 02/05/2019 - 15:49

Am Dienstag, den 05.02.2019, 19:04 +0100 schrieb Miro Hrončok:

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

Re: rpmlint: library-not-linked-against-libc (parts of Python st

By Florian Weimer at 02/07/2019 - 13:53

* Björn 'besser82' Esser:

Unfortunately, it is not possible to check for underlinking in this way.
If something is not linked against glibc, it will not have the GLIBC_2.*
symbol versions because the link editor was not told to resolve function
symbols against glibc, so they are just any other undefined symbol.

You need to look at the symbol names themselves and determine, based on
the names, if expected symbol versions are missing.

Thanks,
Florian

Re: rpmlint: library-not-linked-against-libc (parts of Python st

By Dridi Boukelmoune at 02/05/2019 - 15:09

On Tue, Feb 5, 2019 at 8:03 PM Miro Hrončok < ... at redhat dot com> wrote:
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