* Pavel Valena:
> - Original Message -
>> From: "Florian Weimer"
>> To: "Pavel Valena"
>> Cc: devel@lists.fedoraproject.org
>> Sent: Tuesday, May 14, 2019 10:47:41 AM
>> Subject: Re: rpmlint: library-not-linked-against-libc (parts of
- Original Message -
> From: "Florian Weimer"
> To: "Pavel Valena"
> 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
The same occurs with Ruby:
https://src.fedoraproject.org/rpms/ruby/pull-request/44
Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora
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 e
* 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
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
> > > __sta
* 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
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 th
* 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
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
* 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
* 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 ra
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
On Tue, Feb 5, 2019, 20:03 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-de
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-
On Tue, Feb 5, 2019 at 8:03 PM 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
>
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
18 matches
Mail list logo
