On 7/27/21 1:19 PM, Florian Weimer wrote:
So if there's any change regarding LIBPTHREAD_SO, I think the natural one
would be to define it to LIBC_SO (I hope the dlopen/dlsym case works
regardless of whether that change is made or not).
That is in an interesting idea. I like it.
Me too.
It d
* Joseph Myers:
> On Sat, 17 Jul 2021, Bruno Haible wrote:
>
>> 2) /usr/include/gnu/lib-names.h still defines LIBPTHREAD_SO.
>>How about not defining LIBPTHREAD_SO, since linking with it is supposed
>>to be a no-op in these newer glibc versions?
>
> I think LIBPTHREAD_SO is really for use
On Sat, 17 Jul 2021, Bruno Haible wrote:
> 2) /usr/include/gnu/lib-names.h still defines LIBPTHREAD_SO.
>How about not defining LIBPTHREAD_SO, since linking with it is supposed
>to be a no-op in these newer glibc versions?
I think LIBPTHREAD_SO is really for use with dlopen (followed by e
Hi Florian,
> > 1) I understand that it's only for glibc >= 2.34 on Linux (NPTL),
> >right? Not on Hurd (HTL)?
>
> Yes, Hurd hasn't been integrated.
>
> > 2) /usr/include/gnu/lib-names.h still defines LIBPTHREAD_SO.
> >How about not defining LIBPTHREAD_SO, since linking with it is suppos
Florian Weimer wrote on 2021-04-28:
> However, you should really remove those weak symbol
> hacks. They won't have any effect for glibc 2.34
Done as follows. Tested on a Fedora Rawhide from today.
Thanks for the suggestion.
2021-07-17 Bruno Haible
Don't use '#pragma weak' for thread
* Bruno Haible:
> Florian Weimer wrote on 2021-04-28:
>> However, you should really remove those weak symbol
>> hacks. They won't have any effect for glibc 2.34
>
> I'm trying to do this now. But what is the right condition?
>
> 1) I understand that it's only for glibc >= 2.34 on Linux (NPTL),
>
Florian Weimer wrote on 2021-04-28:
> However, you should really remove those weak symbol
> hacks. They won't have any effect for glibc 2.34
I'm trying to do this now. But what is the right condition?
1) I understand that it's only for glibc >= 2.34 on Linux (NPTL),
right? Not on Hurd (HTL)?
On Tue, 13 Jul 2021 at 03:37, Florian Weimer wrote:
> * Matthias Klose:
>
> > On 7/12/21 5:03 PM, Florian Weimer via Binutils wrote:
> >> * Michael Hudson-Doyle:
> >>
> >>> Did this thread ever reach a conclusion? I'm testing a snapshot of
> >>> glibc 2.34 in ubuntu and running into this issue --
On 7/12/21 5:03 PM, Florian Weimer via Binutils wrote:
> * Michael Hudson-Doyle:
>
>> Did this thread ever reach a conclusion? I'm testing a snapshot of
>> glibc 2.34 in ubuntu and running into this issue -- bison segfaults on
>> startup on ppc64el.
> We rebuilt bison and a couple of other packag
* Matthias Klose:
> On 7/12/21 5:03 PM, Florian Weimer via Binutils wrote:
>> * Michael Hudson-Doyle:
>>
>>> Did this thread ever reach a conclusion? I'm testing a snapshot of
>>> glibc 2.34 in ubuntu and running into this issue -- bison segfaults on
>>> startup on ppc64el.
>
>> We rebuilt bison
* Michael Hudson-Doyle:
> Did this thread ever reach a conclusion? I'm testing a snapshot of
> glibc 2.34 in ubuntu and running into this issue -- bison segfaults on
> startup on ppc64el.
For us it got resolved with a binutils fix:
commit b293661219c36e72acb80502a86b51160bb88cfd
Author: Alan Mod
On Tue, 27 Apr 2021 at 17:53, Florian Weimer wrote:
> lib/glthread/lock.h has this:
>
> | /* The way to test at runtime whether libpthread is present is to test
> |whether a function pointer's value, such as &pthread_mutex_init, is
> |non-NULL. However, some versions of GCC have a bug th
On 2021-04-27, H.J. Lu via Binutils wrote:
On Tue, Apr 27, 2021 at 7:10 PM H.J. Lu wrote:
On Tue, Apr 27, 2021 at 6:57 PM Bruno Haible wrote:
>
> Hi Florian,
>
> > Here's a fairly representative test case, I think.
> >
> > #include
> > #include
> >
> > extern __typeof (pthread_key_create) _
On Tue, Apr 27, 2021 at 07:53:16AM +0200, Florian Weimer via Binutils wrote:
> So the net effect is this:
>
> if (pthread_mutexattr_gettype != NULL)
> pthread_once (control, callback);
>
> Dynamic linking with weak symbols is not very well-defined. On x86-64,
> the link editor produces the
* Bruno Haible:
>> I spent today on coming up with a workaround in glibc.
>
> These are the workarounds I can see:
> - Delay the planned changes in glibc by 5 years or so, to minimize
> the number of binaries out there that would crash. (Probably not what
> you want.)
Nah, those binarie
Hi Florian,
> > So, in the normal cases (link with '-lpthread', link without '-lpthread',
> > and even with dlopen()), everything will work fine. The only problematic
> > case thus is the the use of LD_PRELOAD. Right?
>
> LD_PRELOAD and glibc 2.34 as originally planned.
> ...
> > In other words,
On Wed, Apr 28, 2021 at 7:40 AM Bruno Haible wrote:
> So, in the normal cases (link with '-lpthread', link without '-lpthread',
> and even with dlopen()), everything will work fine. The only problematic
> case thus is the the use of LD_PRELOAD. Right?
>
> I think few packages in a distro will be a
* Bruno Haible:
> So, in the normal cases (link with '-lpthread', link without '-lpthread',
> and even with dlopen()), everything will work fine. The only problematic
> case thus is the the use of LD_PRELOAD. Right?
LD_PRELOAD and glibc 2.34 as originally planned.
> I think few packages in a dis
* Bruno Haible:
> I'm confused again. Are you saying that the crash will occur when old
> binaries are being used with glibc 2.34 also *without* LD_PRELOAD?
Yes, that's how we discovered it. And really is a problem.
Thanks,
Florian
Florian Weimer wrote:
> > $ gcc -Wall -fpie -pie foo.c ; ./a.out
> > initialization code
> >
> > $ gcc -Wall -fpie -pie foo.c -Wl,--no-as-needed -lpthread ; ./a.out
> > multi-threaded initialization
> > initialization code
> >
> > What will change for this program with glibc 2.34?
>
> If recompil
Hi Florian,
Thank you for the details.
> > In which situations will it crash?
> >
> > (a) when the code is in an executable, that gets linked with '-lpthread'
> > and that does not use dlopen()?
>
> The pthread_mutexattr_gettype is defined, but also pthread_once and the
> weak symbols, s
Hello,
On Wed, 28 Apr 2021, Florian Weimer via Binutils wrote:
> > commit 954b63d4c8645f86e40c7ef6c6d60acd2bf019de
> > Author: Alan Modra
> > Date: Wed Apr 19 01:26:57 2017 +0930
> >
> > Implement -z dynamic-undefined-weak
> >
> > -z nodynamic-undefined-weak is only implemented for x86
* H. J. Lu via Libc-alpha:
> Alan extended the fix to PPC:
>
> commit 954b63d4c8645f86e40c7ef6c6d60acd2bf019de
> Author: Alan Modra
> Date: Wed Apr 19 01:26:57 2017 +0930
>
> Implement -z dynamic-undefined-weak
>
> -z nodynamic-undefined-weak is only implemented for x86. (The sparc
>
* Bruno Haible:
> You write:
>> Dynamic linking with weak symbols is not very well-defined. ...
>> the code will crash if pthread_mutexattr_gettype is ever defined.
>
> In which situations will it crash?
>
> (a) when the code is in an executable, that gets linked with '-lpthread'
> and th
* Bruno Haible:
> Hi Florian,
>
>> Here's a fairly representative test case, I think.
>>
>> #include
>> #include
>>
>> extern __typeof (pthread_key_create) __pthread_key_create __attribute__
>> ((weak));
>> extern __typeof (pthread_once) pthread_once __attribute__ ((weak));
>>
>> void
>> f1
On Tue, Apr 27, 2021 at 7:10 PM H.J. Lu wrote:
>
> On Tue, Apr 27, 2021 at 6:57 PM Bruno Haible wrote:
> >
> > Hi Florian,
> >
> > > Here's a fairly representative test case, I think.
> > >
> > > #include
> > > #include
> > >
> > > extern __typeof (pthread_key_create) __pthread_key_create __att
On Tue, Apr 27, 2021 at 6:57 PM Bruno Haible wrote:
>
> Hi Florian,
>
> > Here's a fairly representative test case, I think.
> >
> > #include
> > #include
> >
> > extern __typeof (pthread_key_create) __pthread_key_create __attribute__
> > ((weak));
> > extern __typeof (pthread_once) pthread_onc
Hi Florian,
> Here's a fairly representative test case, I think.
>
> #include
> #include
>
> extern __typeof (pthread_key_create) __pthread_key_create __attribute__
> ((weak));
> extern __typeof (pthread_once) pthread_once __attribute__ ((weak));
>
> void
> f1 (void)
> {
> puts ("f1 called
Hi Florian,
> This will become an urgent issue with glibc 2.34
Thank you for the early heads-up.
I would like to understand the scope and the severity of the issue.
You write:
> Dynamic linking with weak symbols is not very well-defined. ...
> the code will crash if pthread_mutexattr_gettype i
Andreas Schwab wrote:
> It is likely that the use of weak pthread symbols is not confined to
> gnulib.
Yes. Between 2000 and 2010 I heard a couple of times "Multithreading
support is only available through libpthread. It is a common technique
to use weak symbols to distinguish a program linked wit
* Andreas Schwab:
> On Apr 27 2021, Florian Weimer via Binutils wrote:
>
>> I think we can provide an libBrokenGnulib.so preload module which
>> defines pthread_mutexattr_gettype to zero (as an absolute address), so
>> there is a kludge to keep old binaries working, but this is really
>> something
On Apr 27 2021, Florian Weimer via Binutils wrote:
> I think we can provide an libBrokenGnulib.so preload module which
> defines pthread_mutexattr_gettype to zero (as an absolute address), so
> there is a kludge to keep old binaries working, but this is really
> something that must be fixed in gnu
I'm still not quite following, but the message I'm getting is "don't
mess with dynamic detection of whether the pthread functions are linked
in, because there's no way to do it reliably." If so, I suppose Gnulib
will have to require pthread to be linked into all libraries that use
any of these
* Paul Eggert:
> On 4/26/21 10:53 PM, Florian Weimer via Libc-alpha wrote:
>> This will become an urgent issue with glibc 2.34, which defines
>> pthread_mutexattr_gettype unconditionally. Certain gnulib modules will
>> stop working until the binaries are relinked.
>
> Thanks for mentioning this.
On 4/26/21 10:53 PM, Florian Weimer via Libc-alpha wrote:
This will become an urgent issue with glibc 2.34, which defines
pthread_mutexattr_gettype unconditionally. Certain gnulib modules will
stop working until the binaries are relinked.
Thanks for mentioning this. But in what sense will the
lib/glthread/lock.h has this:
| /* The way to test at runtime whether libpthread is present is to test
|whether a function pointer's value, such as &pthread_mutex_init, is
|non-NULL. However, some versions of GCC have a bug through which, in
|PIC mode, &foo != NULL always evaluates to
36 matches
Mail list logo
