Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-19 Thread Ralf Wildenhues
* Eli Zaretskii wrote on Wed, Jul 20, 2011 at 08:38:24AM CEST: > > > I'm afraid this cure would be worse than the disease. > > > > I feel there's some kind of misunderstanding here, because with my > > proposal, nothing will happen that doesn't already happen. Perhaps > > you could show in more d

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-19 Thread Ralf Wildenhues
Hello, * Eli Zaretskii wrote on Wed, Jul 20, 2011 at 08:29:38AM CEST: > > From: Paul Eggert > > > And this would occur every time one does a 'make', even when there's > > no real work to do. > > This occurs already: these headers are regenerated every time I re-run > the `configure' script. Ye

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-19 Thread Eli Zaretskii
> Date: Wed, 20 Jul 2011 02:29:38 -0400 > From: Eli Zaretskii > Cc: 9...@debbugs.gnu.org, bug-gnulib@gnu.org > > > The unnecessary "make" actions would fill up people's screens, > > and would be confusing. > > They fill up my screen already, as things are now. > > > I'm afraid this cure would b

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-19 Thread Eli Zaretskii
> Date: Tue, 19 Jul 2011 22:58:48 -0700 > From: Paul Eggert > CC: 9...@debbugs.gnu.org, bug-gnulib@gnu.org > > On 07/19/2011 10:24 PM, Eli Zaretskii wrote: > > What I'm suggesting is to replace the last command ("mv $@-t $@") with > > this: > > > > move-if-change $@-t $@ > > > > That's it.

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-19 Thread Paul Eggert
On 07/19/2011 10:24 PM, Eli Zaretskii wrote: What I'm suggesting is to replace the last command ("mv $@-t $@") with this: move-if-change $@-t $@ That's it. Make will indeed cheerfully regenerate unistd.h-t ... and alloca.h-t. And getopt.h-t. And the other ten .h-t files that are gener

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-19 Thread Eli Zaretskii
> Date: Tue, 19 Jul 2011 17:39:38 -0700 > From: Paul Eggert > Cc: bug-gnulib > > [cc'ing bug-gnulib as it's related; see > ] > > > It used to be the case that if the results of running `configure' > > didn't change anything of essence, "make"

Re: new module timer-time

2011-07-19 Thread Bruno Haible
Pádraig Brady wrote: > [timer-time.diff attachment] > +Check for timer_settime. Within HAVE_TIMER_SETTIME one can > +assume timer_create is available too, as that is a > +prerequisite to use timer_settime. And timer_gettime as well. I've verified in the platformsxsymbols matrix that timer_create

Re: threadlib and emacs

2011-07-19 Thread Bruno Haible
Hi Paul, > It's fine that Gnulib supports > threadlib, but Gnulib shouldn't insist on threadlib as opposed to > POSIX threads. > ... > POSIX threads are not perfect, but they're part of a standard > interface that is reasonably well understood and they are good enough > for many applications. Gnu

Re: 24.0.50; ./configure causes massive recompilation

2011-07-19 Thread Paul Eggert
[cc'ing bug-gnulib as it's related; see ] > It used to be the case that if the results of running `configure' > didn't change anything of essence, "make" would do nothing. This > worked by producing the generated files under temporary names and

Re: git, merging patches

2011-07-19 Thread Bruno Haible
Hi Paul, > > it is more appropriate to merge patches together and remove reverted > > patches from the history and the ChangeLog. > > Here's a combined patch that should do that. It reflects my most > recent proposal of leaving the dependencies alone. Thanks a lot for taking the extra minutes t

Re: bug#9101: timeout should use setitimer if available

2011-07-19 Thread Paul Eggert
On 07/19/11 15:24, Pádraig Brady wrote: > How about just adding a module to gnulib > where others might find it useful too? Yes, that's better, thanks. Could you please add Jim and me to the maintainer list?

Re: bug#9101: timeout should use setitimer if available

2011-07-19 Thread Pádraig Brady
On 19/07/11 19:45, Paul Eggert wrote: > On 07/19/11 04:00, Pádraig Brady wrote: > >> + if (timer_create (CLOCK_REALTIME, NULL, &timerid) == -1) >> +error (EXIT_FAILURE, errno, _("error in timer_create")); >> + if (timer_settime (timerid, 0, &its, NULL) == -1) >> +error (EXIT_FAILURE, err

Re: strstr is linear test fails on my machine with glibc 2.13

2011-07-19 Thread Eric Blake
On 07/19/2011 03:45 PM, Bruno Haible wrote: Eric Blake wrote: Known glibc bug when using glibc 2.11 or newer on an SSE4.2-enabled chip: http://sourceware.org/bugzilla/show_bug.cgi?id=12100 Unless it is fixed, let's update the comments and cross-compilation guess. @@ -93,13 +93,15 @@ re

Re: strerror_r replaced on linux?

2011-07-19 Thread Eric Blake
On 07/19/2011 03:47 PM, Sam Steingold wrote: Hi, ./config.log:REPLACE_STRERROR_R='1' why do I see this on Linux 2.6.18-238.9.1.el5 gcc (GCC) 4.1.2 20080704 glibc-2.5-58.el5_6.3 Because glibc 2.5, and even glibc 2.13, has buggy strerror_r. Read gnulib/doc/posix-functions/strerror_r.texi for d

Re: strstr is linear test fails on my machine with glibc 2.13

2011-07-19 Thread Bruno Haible
Eric Blake wrote: > Known glibc bug when using glibc 2.11 or newer on an SSE4.2-enabled chip: > http://sourceware.org/bugzilla/show_bug.cgi?id=12100 Unless it is fixed, let's update the comments and cross-compilation guess. 2011-07-19 Bruno Haible strstr: Update cross-compilation gue

Re: HAVE_LC_MESSAGES

2011-07-19 Thread Bruno Haible
Sam Steingold wrote: > also, can I now remove gt_LC_MESSAGES from configure.in? If HAVE_LC_MESSAGES is nowhere used any more, then yes, you can remove the invocation of gt_LC_MESSAGES. Bruno -- In memoriam Paul Schneider

strerror_r replaced on linux?

2011-07-19 Thread Sam Steingold
Hi, ./config.log:REPLACE_STRERROR_R='1' why do I see this on Linux 2.6.18-238.9.1.el5 gcc (GCC) 4.1.2 20080704 glibc-2.5-58.el5_6.3 -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://www.memritv.org http://iris.org.il http://dhimmi.com http://ffii.or

Re: [PATCH] getopt-gnu: avoid crash in glibc getopt

2011-07-19 Thread Pádraig Brady
On 19/07/11 20:33, Bruno Haible wrote: > Eric Blake asked: >>> Does nocrash.m4 prevent core files on Linux, or is it just for >>> preventing modal popup boxes on other OS? > > The comments in m4/nocrash.m4 say it: > >...This is useful to avoid triggering >action from a background debugger

Re: [PATCH] getopt-gnu: avoid crash in glibc getopt

2011-07-19 Thread Bruno Haible
Eric Blake asked: > > Does nocrash.m4 prevent core files on Linux, or is it just for > > preventing modal popup boxes on other OS? The comments in m4/nocrash.m4 say it: ...This is useful to avoid triggering action from a background debugger and to avoid core dumps. Pádraig Brady wrote: > N

Re: [libvirt] mingw: test-poll pipe part fails

2011-07-19 Thread Bastien ROUCARIES
n Tue, Jul 19, 2011 at 6:54 PM, Bastien ROUCARIES wrote: > I have some code if you want that work. If you could test, I wil lsend > you. I have no time to create m4 and proper gnulib integration. It is > up to you Please test, I do not even have compiled it. > Bastien > > On Tue, Jul 19, 2011 at

Re: [libvirt] mingw: test-poll pipe part fails

2011-07-19 Thread Bastien ROUCARIES
I have some code if you want that work. If you could test, I wil lsend you. I have no time to create m4 and proper gnulib integration. It is up to you Bastien On Tue, Jul 19, 2011 at 5:44 PM, Daniel P. Berrange wrote: > On Tue, Jul 19, 2011 at 09:31:59AM -0600, Eric Blake wrote: >> On 07/19/2011

Re: [PATCH] getopt-gnu: avoid crash in glibc getopt

2011-07-19 Thread Eric Blake
On 07/19/2011 10:31 AM, Pádraig Brady wrote: Does nocrash.m4 prevent core files on Linux, or is it just for preventing modal popup boxes on other OS? It prevents cores on Linux at least. Note my Fedora system is configured to include pids in the core files, and the generic ./configure cleanup c

Re: [PATCH] getopt-gnu: avoid crash in glibc getopt

2011-07-19 Thread Pádraig Brady
On 19/07/11 16:34, Eric Blake wrote: > On 07/19/2011 03:55 AM, Pádraig Brady wrote: >> On 07/07/11 17:57, Eric Blake wrote: >>> Use of "W;" in an option string may be rare, but we might as well >>> avoid crashing on it. >>> >>> * m4/getopt.m4 (gl_GETOPT_CHECK_HEADRS): Detect the problem. >> >> I no

Re: strstr is linear test fails on my machine with glibc 2.13

2011-07-19 Thread Eric Blake
On 07/19/2011 09:30 AM, Reuben Thomas wrote: I was interested to see this test fail, and digging inside, see comments assert that glibc> 2.12 should be OK. Looks therefore as if something's wrong. I'm using the glibc 2.13 shipped with Ubuntu natty on an x86_64 system. The test exits with status

Re: [libvirt] mingw: test-poll pipe part fails

2011-07-19 Thread Eric Blake
On 07/19/2011 09:30 AM, Daniel P. Berrange wrote: I'm wondering if the problem here is that libvirt is trying to use the pipe-to-self mechanism as a fundamental event loop idiom. That is, the reason libvirt is calling poll is in order to minimize CPU until something interesting happens, where in

Re: [libvirt] mingw: test-poll pipe part fails

2011-07-19 Thread Daniel P. Berrange
On Tue, Jul 19, 2011 at 09:31:59AM -0600, Eric Blake wrote: > On 07/19/2011 09:30 AM, Daniel P. Berrange wrote: > >>I'm wondering if the problem here is that libvirt is trying to use the > >>pipe-to-self mechanism as a fundamental event loop idiom. That is, the > >>reason libvirt is calling poll i

Re: Is the module unused-parameter incomplete?

2011-07-19 Thread Eric Blake
On 07/19/2011 04:36 AM, Mats E Andersson wrote: Dear all, the module 'unused-parameter' seems to be still incomplete, since it resides in 'modules/snippet/unused-parameter'. Rather, the module changed names, and you need to update your bootstrap.conf to reflect that name change, as documented

strstr is linear test fails on my machine with glibc 2.13

2011-07-19 Thread Reuben Thomas
I was interested to see this test fail, and digging inside, see comments assert that glibc > 2.12 should be OK. Looks therefore as if something's wrong. I'm using the glibc 2.13 shipped with Ubuntu natty on an x86_64 system. The test exits with status 142, i.e. 128 + 14, i.e. the 5-second alarm has

Re: HAVE_LC_MESSAGES

2011-07-19 Thread Sam Steingold
> * Sam Steingold [2011-07-14 17:57:10 -0400]: > >> * Bruno Haible [2011-07-14 23:18:41 +0200]: >> >> Sam Steingold asked: >>> Does clisp need to know whether LC_MESSAGES is supported by the system, >>> or is a fake one defined by libintl or gnulib. >>> ... >>> > No, this is not needed: gettext's

Re: [PATCH] getopt-gnu: avoid crash in glibc getopt

2011-07-19 Thread Eric Blake
On 07/19/2011 03:55 AM, Pádraig Brady wrote: On 07/07/11 17:57, Eric Blake wrote: Use of "W;" in an option string may be rare, but we might as well avoid crashing on it. * m4/getopt.m4 (gl_GETOPT_CHECK_HEADRS): Detect the problem. I noticed core files which are due to this I think. Should it

Re: [libvirt] mingw: test-poll pipe part fails

2011-07-19 Thread Daniel P. Berrange
On Thu, Jun 30, 2011 at 11:56:15AM -0600, Eric Blake wrote: > [adding libvirt] > > On 06/04/2011 12:24 AM, Paolo Bonzini wrote: > > On Sat, Jun 4, 2011 at 00:37, Matthias Bolte > > wrote: > >> After testing a while and reading MSDN docs the problem seems to be > >> that MsgWaitForMultipleObjects

Is the module unused-parameter incomplete?

2011-07-19 Thread Mats E Andersson
Dear all, the module 'unused-parameter' seems to be still incomplete, since it resides in 'modules/snippet/unused-parameter'. At present I must manually copy 'unused-parameters.h' for GNU Inetutils into 'lib/' each time when bootstrapping, in order to build the source tree. Yes, the module is nam

Re: [PATCH] getopt-gnu: avoid crash in glibc getopt

2011-07-19 Thread Pádraig Brady
On 07/07/11 17:57, Eric Blake wrote: > Use of "W;" in an option string may be rare, but we might as well > avoid crashing on it. > > * m4/getopt.m4 (gl_GETOPT_CHECK_HEADRS): Detect the problem. I noticed core files which are due to this I think. Should it be protected with m4/nocrash.m4 ? cheers

Re: git, merging patches

2011-07-19 Thread Paul Eggert
On 07/18/11 18:05, Bruno Haible wrote: > it is more appropriate to merge patches together and remove reverted > patches from the history and the ChangeLog. Here's a combined patch that should do that. It reflects my most recent proposal of leaving the dependencies alone. I took the liberty of us

Re: git, merging patches

2011-07-19 Thread Paul Eggert
On 07/18/11 18:05, Bruno Haible wrote: > it is more appropriate to merge patches together and remove reverted > patches from the history and the ChangeLog. Sure, I can do that next time. It shouldn't be much work.

Re: threadlib and emacs

2011-07-19 Thread Paul Eggert
On 07/18/11 17:38, Bruno Haible wrote: > [the new patch] does not address the points 1) and 2) of > . That comment's point (1a) is the claim that some more-complicated and not-yet-implemented approach would be better. Perhaps it