On 09/20/2010 05:43 PM, Gary V. Vaughan wrote:
> Hmm... looking at gnulib/pthread.h, am I right in assuming that
> threads are now effectively disabled by gnulib on the mac in favour
> of a selection of stub functions? In which case, I suppose those
> warnings indicate that glthread/lock.c may at
On 21 September 2010 01:07, Bruno Haible wrote:
> Reuben,
>
>> Heh. My point precisely: 3 functions and 50 lines versus 1 flag and 5
>> lines (RE_PLAIN) to solve the same problem
>
> I agree that if we had the opportunity to invent regex APIs from scratch
> now, all 4 syntaxes (literals, wildcards
Hi Paul,
> The problem is that the gnulib i18n code includes pthread.h for its
> own purposes
I wouldn't call it "the gnulib i18n code". The modules 'lock', 'tls',
etc. are needed by the modules 'strsignal', 'fstrcmp', and 'localename'.
Basically, every piece of code that wants to provide multit
Hello,
influenced by an exchange with Simon Josefsson, where we have
on issue with the present matter in GNU Inetutils, I would like
to mention this subject, since GNUlib seems not to resolve the
matter to our satisfaction!
In OpenBSD (definitely in 4.6) there is a POSIX violation,
quoting Simon
As an initial response to this problem, I'm installing a self check of
the net/if.h interface. See below. Mats, if you could quote the
compiler errors you get when building the self-check below on OpenBSD,
that would be useful. The next step is to see how gnulib can provide a
replacement that wo
Reuben Thomas writes:
> Attached, to make the whitespace in the Makefile.am example more
> copy-and-paste friendly.
Applied, thanks.
> By the way, is there some reason to keep this file and pmccabe.css in
> gnulib rather than push it upstream to pmccabe, and make the gnulib
> module just make t
Reuben Thomas writes:
> On 20 September 2010 15:49, Eric Blake wrote:
>> Rather than describing the fix, could you post this as a patch?
>
> Sorry; you've made me realise that my habit of not posting patches for
> code I'm not sure about is silly for several reasons.
>
> Patch attached. I've add
Reuben Thomas writes:
> Are the mentions of GSS in the section "Out of memory handling" bogus
> cut-and-paste-o's or similar? A bit of googling suggests that the text
> has indeed been cut and pasted from the GNU GSS manual. It seems that
> this section is essentially meant to document xalloc_die
Reuben Thomas writes:
> 1. The example Makefile.am code has "lib/" rather than "src/" in the
> path to the source code, even though it's clearly the package source
> that is to be analysed, not the gnulib library code.
This is because it is an example, and the projects I used it for had the
"rea
On 21 September 2010 13:28, Simon Josefsson wrote:
> Reuben Thomas writes:
>> By the way, is there some reason to keep this file and pmccabe.css in
>> gnulib rather than push it upstream to pmccabe, and make the gnulib
>> module just make the test and suggest an appropriate Makefile.am patch
>> w
On 21 September 2010 13:38, Simon Josefsson wrote:
> Reuben Thomas writes:
>
>> 1. The example Makefile.am code has "lib/" rather than "src/" in the
>> path to the source code, even though it's clearly the package source
>> that is to be analysed, not the gnulib library code.
>
> This is because
On 21 September 2010 13:34, Simon Josefsson wrote:
> Reuben Thomas writes:
>
>> Are the mentions of GSS in the section "Out of memory handling" bogus
>> cut-and-paste-o's or similar? A bit of googling suggests that the text
>> has indeed been cut and pasted from the GNU GSS manual. It seems that
tisdag den 21 september 2010 klockan 14:22 skrev Simon Josefsson detta:
> As an initial response to this problem, I'm installing a self check of
> the net/if.h interface. See below. Mats, if you could quote the
> compiler errors you get when building the self-check below on OpenBSD,
> that would
Mats Erik Andersson writes:
> tisdag den 21 september 2010 klockan 14:22 skrev Simon Josefsson detta:
>> As an initial response to this problem, I'm installing a self check of
>> the net/if.h interface. See below. Mats, if you could quote the
>> compiler errors you get when building the self-ch
Reuben Thomas writes:
> On 21 September 2010 13:38, Simon Josefsson wrote:
>> Reuben Thomas writes:
>>
>>> 1. The example Makefile.am code has "lib/" rather than "src/" in the
>>> path to the source code, even though it's clearly the package source
>>> that is to be analysed, not the gnulib lib
Reuben Thomas writes:
> On 21 September 2010 13:28, Simon Josefsson wrote:
>> Reuben Thomas writes:
>>> By the way, is there some reason to keep this file and pmccabe.css in
>>> gnulib rather than push it upstream to pmccabe, and make the gnulib
>>> module just make the test and suggest an appr
Reuben Thomas writes:
> On 21 September 2010 13:34, Simon Josefsson wrote:
>> Reuben Thomas writes:
>>
>>> Are the mentions of GSS in the section "Out of memory handling" bogus
>>> cut-and-paste-o's or similar? A bit of googling suggests that the text
>>> has indeed been cut and pasted from the
On 21 September 2010 14:55, Simon Josefsson wrote:
> Reuben Thomas writes:
>
>> On 21 September 2010 13:38, Simon Josefsson wrote:
>>> Reuben Thomas writes:
>>>
1. The example Makefile.am code has "lib/" rather than "src/" in the
path to the source code, even though it's clearly the p
On 21 September 2010 14:57, Simon Josefsson wrote:
>
> Sounds good -- please also forward any patches we have (I don't think
> there are many except for your recent stuff though?).
>
> I still think it makes sense to have a copy in gnulib, just as gnulib
> contains a copy of many other things pull
On 21 September 2010 14:59, Simon Josefsson wrote:
> The intent was to document how the xalloc-die module is used by many
> other modules in gnulib to handle out of memory conditions. Maybe you
> are right and it is no longer useful to have in the manual, as it could
> be documented in the xalloc
On 09/21/2010 06:22 AM, Simon Josefsson wrote:
As an initial response to this problem, I'm installing a self check of
the net/if.h interface. See below. Mats, if you could quote the
compiler errors you get when building the self-check below on OpenBSD,
that would be useful. The next step is to
On Mon, Sep 20, 2010 at 8:55 AM, Bruce Korb wrote:
>> of determining whether you are
>> running from within a git repository, and there is no such command
>> as 'git root'.
>
> Sorry. BitKeeper had it and the method for accomplishing it was
> too complicated, so I added an alias and forgot I'd d
Hi,
On Tue, Sep 21, 2010 at 8:50 AM, Matt Rice wrote:
>> There is an approved way, but it is really obtuse:
>> $(\cd ./$(git rev-parse --show-cdup) && pwd -P)
>> Far from the first thing that comes to mind.
>
> hmm, even this doesn't seem to work when the GIT_DIR
> environment variable is set
I
On Tue, Sep 21, 2010 at 9:17 AM, Bruce Korb wrote:
> Hi,
>
> On Tue, Sep 21, 2010 at 8:50 AM, Matt Rice wrote:
>>> There is an approved way, but it is really obtuse:
>>> $(\cd ./$(git rev-parse --show-cdup) && pwd -P)
>>> Far from the first thing that comes to mind.
>>
>> hmm, even this doesn't
tisdag den 21 september 2010 klockan 15:52 skrev Simon Josefsson detta:
> Mats Erik Andersson writes:
>
> > tisdag den 21 september 2010 klockan 14:22 skrev Simon Josefsson detta:
> >> As an initial response to this problem, I'm installing a self check of
> >> the net/if.h interface. See below.
Mats Erik Andersson wrote:
> In OpenBSD (definitely in 4.6) there is a POSIX violation,
> quoting Simon here, since the header file states
>
> ### /usr/include/net/if.h
>
> #define if_freenameindex(x) free(x)
>
> This macro causes difficulties ...
Indeed, according to POSIX:2008 [1], a
On 09/21/10 03:43, Bruno Haible wrote:
> The modules 'lock', 'tls',
> etc. are needed by the modules 'strsignal', 'fstrcmp', and 'localename'.
> Basically, every piece of code that wants to provide multithreaded
> access to a global variable (may it be a registry or cache or anything)
> needs locki
Paul Eggert wrote:
> the problem is that coreutils does not need and does not want
> that multithreaded access, and yet it has to build the multithreaded
> support anyway. ...
> It'd be better if applications could say "I don't need gnulib to be
> multithread-safe, and please don't bother with thr
On 09/21/10 10:40, Bruno Haible wrote:
> You can do so by inserting
> gl_use_threads_default=no
> in your configure.ac, before the invocations of gl_INIT_EARLY and gl_INIT.
Thanks, I didn't know that. I tried it, and found one minor glitch.
"configure" said "checking for multithread API to use.
Gary, could you please also try the following patch to coreutils,
either by itself, or along with the updated gnulib patch? Thanks.
configure: default gnulib to not using threads
* configure.ac: Set gl_use_threads_default=no so that gnulib is
configured without threading. The only coreutils app
Eric Blake writes:
> On 09/21/2010 06:22 AM, Simon Josefsson wrote:
>> As an initial response to this problem, I'm installing a self check of
>> the net/if.h interface. See below. Mats, if you could quote the
>> compiler errors you get when building the self-check below on OpenBSD,
>> that woul
Mats Erik Andersson writes:
> My protocol "report_for_test_net_if.txt" is attached. I am not able
> to compile the test into any working executable for OpenBSD 4.6.
> The mishaps are due to "if_freenameindex".
Thanks, this is very useful.
Is there a if_freenameindex symbol in the OpenBSD libc?
Bruno Haible writes:
> Mats Erik Andersson wrote:
>> In OpenBSD (definitely in 4.6) there is a POSIX violation,
>> quoting Simon here, since the header file states
>>
>> ### /usr/include/net/if.h
>>
>> #define if_freenameindex(x) free(x)
>>
>> This macro causes difficulties ...
>
> Ind
Reuben Thomas writes:
> On 21 September 2010 14:59, Simon Josefsson wrote:
>> The intent was to document how the xalloc-die module is used by many
>> other modules in gnulib to handle out of memory conditions. Maybe you
>> are right and it is no longer useful to have in the manual, as it could
On 09/21/2010 02:41 PM, Simon Josefsson wrote:
Eric Blake writes:
On 09/21/2010 06:22 AM, Simon Josefsson wrote:
As an initial response to this problem, I'm installing a self check of
the net/if.h interface. See below. Mats, if you could quote the
compiler errors you get when building the s
>>/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o libposix.la -rpath
>>/usr/local/lib .libs/*.o asnprintf.o \
>> basename-lgpl.o chdir-long.o cloexec.o dirname-lgpl.o dprintf.o dup-safer.o
>> duplocale.o fcntl.o\
>> fd-safer.o fflush.o filenamecat-lgpl.o fprintf.o fpurge.o fseek.o fsee
tisdag den 21 september 2010 klockan 22:46 skrev Simon Josefsson detta:
> Mats Erik Andersson writes:
>
> > My protocol "report_for_test_net_if.txt" is attached. I am not able
> > to compile the test into any working executable for OpenBSD 4.6.
> > The mishaps are due to "if_freenameindex".
>
>
On 21 September 2010 21:51, Simon Josefsson wrote:
> Thanks, applied. I didn't see a patch for ChangeLog in there though? I
> added it myself and pushed it separately.
I used git format-patch, which seemed to put my ChangeLog entry at the
top. I see that that is not specifically a patch to Chan
I was testing multi-byte enhancements to coreutils/join with:
LC_ALL=en_US.utf8 join -i <(env printf '1\x00\n') <(env printf '2\x00\n')
and noticed it spun the CPU because of the NUL char.
The attached fixes the issue for me. This function is supposed
to skip over NUL chars like this right?
cheers
Hi Paul,
On 21 Sep 2010, at 14:49, Paul Eggert wrote:
> Could you try the following patch instead? It tries an idea discussed
> earlier today, namely, fall back on mutexes if spinlocks aren't there.
> You'll need not only to update lib/pthread.in.h and m4/pthread.m4, but
> also to get that code f
On 09/21/2010 10:11 PM, Gary V. Vaughan wrote:
> But the patch causes a bizarre and apparently unrelated compilation
> error:
>
> ; make V=1
> gcc -std=gnu99 -I. -I../lib -g -O2 -MT sigprocmask.o -MD -MP -MF
> .deps/sigprocmask.Tpo -c -o sigprocmask.o ../lib/sigprocmask.c
> ../lib/si
41 matches
Mail list logo
