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
On Tue, Feb 5, 2019 at 8:03 PM Miro Hrončok mhroncok@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
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
* Björn 'besser82' Esser:
$ 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
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.
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
On Tue, Feb 5, 2019, 20:03 Miro Hrončok <mhroncok@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.
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
$ 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
Miro Hrončok
Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 05. 02. 19 19:04, Miro Hrončok 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
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.
* Miro Hrončok:
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.
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
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
* Marcel Plch:
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?
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
On Mon, 2019-02-11 at 18:47 +0100, Florian Weimer wrote
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
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?
* Marcel Plch:
On Mon, 2019-02-11 at 18:47 +0100, Florian Weimer wrote
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
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?
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
On Tue, 2019-02-12 at 15:35 +0100, Florian Weimer wrote:
- Marcel Plch:
On Mon, 2019-02-11 at 18:47 +0100, Florian Weimer wrote
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
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?
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
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?
* Marcel Plch:
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."
Yes, I think that's accurate.
Thanks, Florian
On Tue, 2019-02-12 at 15:52 +0100, Florian Weimer wrote:
- Marcel Plch:
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."
Yes, I think that's accurate.
Thanks, Florian
I think this has clarified the issue. Thank you for the discussion, Florian.
The same occurs with Ruby: https://src.fedoraproject.org/rpms/ruby/pull-request/44
Pavel
* Pavel Valena:
The same occurs with Ruby: https://src.fedoraproject.org/rpms/ruby/pull-request/44
I'm not sure if this is a false positive. I checked fcntl.so, and it references __cxa_finalize, as a weak symbol, so it needs to be linked against libc.so.6, for ABI stability.
Can you figure out the linker command line? It could be a binutils bug in the implementation of --as-needed.
Thanks, Florian
----- Original Message -----
From: "Florian Weimer" fweimer@redhat.com To: "Pavel Valena" pvalena@redhat.com Cc: devel@lists.fedoraproject.org Sent: Tuesday, May 14, 2019 10:47:41 AM Subject: Re: rpmlint: library-not-linked-against-libc (parts of Python stdlib, after gcc 9)
- Pavel Valena:
The same occurs with Ruby: https://src.fedoraproject.org/rpms/ruby/pull-request/44
I'm not sure if this is a false positive. I checked fcntl.so, and it references __cxa_finalize, as a weak symbol, so it needs to be linked against libc.so.6, for ABI stability.
Can you figure out the linker command line? It could be a binutils bug in the implementation of --as-needed.
From Ruby build(rawhide): https://da.gd/jBhE6 https://copr.fedorainfracloud.org/coprs/pvalena/ruby/build/887856/
``` * LDFLAGS: -L. -Wl,-z,relro -Wl,--as-needed -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \ -fstack-protector-strong -rdynamic \ -Wl,-export-dynamic * DLDFLAGS: -Wl,-z,relro -Wl,--as-needed -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld ```
The full command is: ``` gcc -shared -o ../../.ext/x86_64-linux/fcntl.so fcntl.o -L. -L../.. -L. -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -m64 -lruby -lm -lc ``` ________________________________
Wich is different from F29(same SRPM; result linked correctly): ``` * LDFLAGS: -L. -Wl,-z,relro -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \ -fstack-protector-strong -rdynamic \ -Wl,-export-dynamic * DLDFLAGS: -Wl,-z,relro -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld ``` ``` gcc -shared -o ../../.ext/x86_64-linux/fcntl.so fcntl.o -L. -L../.. -L. -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -m64 -lruby -lm -lc ```
Thanks, Florian
HIH,
* Pavel Valena:
----- Original Message -----
From: "Florian Weimer" fweimer@redhat.com To: "Pavel Valena" pvalena@redhat.com Cc: devel@lists.fedoraproject.org Sent: Tuesday, May 14, 2019 10:47:41 AM Subject: Re: rpmlint: library-not-linked-against-libc (parts of Python stdlib, after gcc 9)
- Pavel Valena:
The same occurs with Ruby: https://src.fedoraproject.org/rpms/ruby/pull-request/44
I'm not sure if this is a false positive. I checked fcntl.so, and it references __cxa_finalize, as a weak symbol, so it needs to be linked against libc.so.6, for ABI stability.
Can you figure out the linker command line? It could be a binutils bug in the implementation of --as-needed.
From Ruby build(rawhide): https://da.gd/jBhE6 https://copr.fedorainfracloud.org/coprs/pvalena/ruby/build/887856/
* LDFLAGS: -L. -Wl,-z,relro -Wl,--as-needed -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \ -fstack-protector-strong -rdynamic \ -Wl,-export-dynamic * DLDFLAGS: -Wl,-z,relro -Wl,--as-needed -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ldThe full command is:
gcc -shared -o ../../.ext/x86_64-linux/fcntl.so fcntl.o -L. -L../.. -L. -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -m64 -lruby -lm -lc
Wich is different from F29(same SRPM; result linked correctly):
* LDFLAGS: -L. -Wl,-z,relro -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \ -fstack-protector-strong -rdynamic \ -Wl,-export-dynamic * DLDFLAGS: -Wl,-z,relro -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ldgcc -shared -o ../../.ext/x86_64-linux/fcntl.so fcntl.o -L. -L../.. -L. -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -m64 -lruby -lm -lc
Yes, it's due to the --as-needed change. Problems like this one are expected. The ELF tooling certainly needs to be updated for this change.
Thanks, Florian
On 05. 02. 19 19:04, Miro Hrončok 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...
Do I care? Should I fix something? I honestly have no idea.
[1] https://lintian.debian.org/tags/library-not-linked-against-libc.html
We have new errors on F30+:
python38.x86_64: E: shared-lib-without-dependency-information /usr/lib64/python3.8/lib-dynload/_contextvars.cpython-38-x86_64-linux-gnu.so python38.x86_64: E: shared-lib-without-dependency-information /usr/lib64/python3.8/lib-dynload/_heapq.cpython-38-x86_64-linux-gnu.so python38.x86_64: E: shared-lib-without-dependency-information /usr/lib64/python3.8/lib-dynload/_testimportmultiple.cpython-38-x86_64-linux-gnu.so python38.x86_64: E: shared-lib-without-dependency-information /usr/lib64/python3.8/lib-dynload/_testinternalcapi.cpython-38-x86_64-linux-gnu.so
rpmlint doesn't give much info: $ rpmlint -I shared-lib-without-dependency-information shared-lib-without-dependency-information:
But lintian again explains the issue: https://lintian.debian.org/tags/shared-lib-without-dependency-information.ht...
The listed shared library doesn't include information about which other libraries the library was linked against. (When running "ldd foo.so" ldd should report about these other libraries. In your case, ldd just reports "statically linked".)
I again think this is OK for Python extension modules. Thoughts?
* Miro Hrončok:
On 05. 02. 19 19:04, Miro Hrončok 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...
Do I care? Should I fix something? I honestly have no idea.
[1] https://lintian.debian.org/tags/library-not-linked-against-libc.html
We have new errors on F30+:
python38.x86_64: E: shared-lib-without-dependency-information /usr/lib64/python3.8/lib-dynload/_contextvars.cpython-38-x86_64-linux-gnu.so python38.x86_64: E: shared-lib-without-dependency-information /usr/lib64/python3.8/lib-dynload/_heapq.cpython-38-x86_64-linux-gnu.so python38.x86_64: E: shared-lib-without-dependency-information /usr/lib64/python3.8/lib-dynload/_testimportmultiple.cpython-38-x86_64-linux-gnu.so python38.x86_64: E: shared-lib-without-dependency-information /usr/lib64/python3.8/lib-dynload/_testinternalcapi.cpython-38-x86_64-linux-gnu.so
rpmlint doesn't give much info: $ rpmlint -I shared-lib-without-dependency-information shared-lib-without-dependency-information:
But lintian again explains the issue: https://lintian.debian.org/tags/shared-lib-without-dependency-information.ht...
The listed shared library doesn't include information about which other libraries the library was linked against. (When running "ldd foo.so" ldd should report about these other libraries. In your case, ldd just reports "statically linked".)
I again think this is OK for Python extension modules. Thoughts?
It depends on the extension module. For _contextvars, it's okay because it does not link against anything (glibc or otherwise). Global C++ destructors will not work because of unfulfilled weak reference to __cxa_finalize, but you probably do not care about that.
rpmlint really should have a list of symbols from system libraries that need linking, otherwise there's always going to be false positives for such plugins. (Although extension modules could link against libpython on Fedora because Fedora doesn't use the fat Python interpreter, unlike some other distributions.)
Thanks, Florian
-
Björn 'besser82' Esser -
Dridi Boukelmoune -
Fabio Valentini -
Florian Weimer -
Marcel Plch -
Miro Hrončok -
Pavel Valena