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 - 21: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 - 14: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 Marcel Plch at 02/11/2019 - 12:56

Hello, Florian,

I don't see any problem in this.
Even if an extension function receives a pointer to a local variable,
it should be fine as long as the variable is up the stack. Should it be
downwards, it is undefined behavior anyways, linked or not.
Maybe I have just misunderstood, can you please come up with a specific
scenario, even better an example, where the problem occurs?

Thank you,
Marcel Plch

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

By Florian Weimer at 02/11/2019 - 13:47

* Marcel Plch:

If you take the address of a local variable and pass the resulting
pointer to another function, the compiler will generate a call to
__stack_chk_fail, which lives in glibc. At build time, linking against
glibc is required so that this symbol receives its proper version,
otherwise the resulting binary is invalid and may not be compatible with
future glibc versions.

Thanks,
Florian

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

By Marcel Plch at 02/12/2019 - 10:34

On Mon, 2019-02-11 at 18:47 +0100, Florian Weimer wrote
Since the extensions get the symbols from the Python interpreter on
dynamic load, I can see the risk here in case of third-party software,
where the interpreter gets recompiled against a new glibc version and
the extension is left alone. However, the extensions are recompiled
whenever the interpreter is and so will always be compatible with the
'current' glibc version. There is no need to keep an eye out for future
versions. Or is there?

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

By Florian Weimer at 02/12/2019 - 10:35

* Marcel Plch:

It's certainly possible to run an old Python binary with a newer glibc.

How do you even get an extension that is not linked against glibc when
it uses symbols from glibc? Do you build extensions with -nostdlib? Or
invoke ld directly, instead of gcc/g++?

Thanks,
Florian

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

By Marcel Plch at 02/12/2019 - 10:49

On Tue, 2019-02-12 at 15:35 +0100, Florian Weimer wrote:
I see your point.

So rather than:
"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,"
we can say:
"Some Python extension modules don't need to be linked against glibc
under such condition that they don't use any glibc symbol."

Correct?

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

By Florian Weimer at 02/12/2019 - 10:52

* Marcel Plch:

Yes, I think that's accurate.

Thanks,
Florian

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

By Marcel Plch at 02/12/2019 - 10:56

On Tue, 2019-02-12 at 15:52 +0100, Florian Weimer wrote:
I think this has clarified the issue.
Thank you for the discussion, Florian.

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

By Fabio Valentini at 02/05/2019 - 17: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 - 16: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 - 14: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 - 16: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