* doc/gnulib-tool.texi (Initial import): Don’t mention
AC_PROG_CC_STDC as it’s deprecated in current Autoconf.
* gnulib-tool (func_done_dir): Suggest replacing
AC_PROG_CC_STDC and AC_PROG_CC_C99, as per current Autoconf.
---
ChangeLog| 8
doc/gnulib-tool.texi | 11
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
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
* 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
Hi,
I want to assess the safety and portability of the following trick, for getting
outside poll. Replacing by using dup2 a read poll object by a writtable one. I
think to use this for stopping polling in multithread program
It work really well, and could for instance allow me to tear down
* 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
>>
Hi,
Commit eb32c992 from five days ago causes trouble when trying to compile
GNU nano from git on an older Debian box:
make[4]: Entering directory `/home/bens/NANO/lib'
depbase=`echo malloc/dynarray_at_failure.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -std=gnu11 -DHAVE_CONFIG_H -I.
Thanks for reporting that. I installed the attached into Gnulib to try
to work around the problem. Please give it a try (I haven't tested it on
older Debian).
>From 7b152eb2c2fbabce7eb7b1f789ad6feb0966bbd9 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 27 Apr 2021 11:23:28 -0700
Subject:
On 4/27/21 3:49 PM, Bastien ROUCARIES wrote > It have been 10 year that
we invented passfd API, and it was a huge success.> > I think it is time
to submit this API to next revision of POSIX> > What do you think?
Although I don't use it, it looks like a good API for standardization.
I suggest
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
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)
On Tue, Apr 27, 2021 at 3:47 PM Bastien ROUCARIES
wrote:
>
> Le mar. 27 avr. 2021 à 22:40, Bruno Haible a écrit :
> >
> > Hi Bastien,
> >
> > > I want to assess the safety and portability of the following trick,
> >
> > I would want to help you with this, but I can't. You have not stated:
> >
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
Le mar. 27 avr. 2021 à 22:40, Bruno Haible a écrit :
>
> Hi Bastien,
>
> > I want to assess the safety and portability of the following trick,
>
> I would want to help you with this, but I can't. You have not stated:
> - What is this code supposed to do?
I want to shutdown (2) a pipe, in a
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
Hi Bastien,
> I want to assess the safety and portability of the following trick,
I would want to help you with this, but I can't. You have not stated:
- What is this code supposed to do?
- Why is it a "trick"? What advantages does it have compared to the code
a naïve developer would
Hi,
It have been 10 year that we invented passfd API, and it was a huge success.
I think it is time to submit this API to next revision of POSIX
What do you think?
Bastien
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
19 matches
Mail list logo
