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

[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 detail which Make actions would happen that
> > doesn't happen now.
> 
> Perhaps you thought that a mere "make", even without re-running
> `configure', will trigger these rules.  But that is not the case: as
> long as config.status is not updated, these rules will not be
> triggered, since unistd.h etc. will always be newer than the
> corresponding *.in.h templates, due to the fact that move-if-change
> _will_ overwrite them with newer versions whenever there's a real
> change in the *.in.h templates.
> 
> Am I missing something?

I think you are.  Once config.status is updated, the .h files' rules
are triggered, but since move-if-change never updates identical outputs
they will be triggered every time from then on.

You need a separate stamp file to avoid this.

Cheers,
Ralf

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

[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.

Yes, but 'make' is run a lot more often than 'configure' in some
workflows.  I think one implicit gnulib expectation is that configure
is not run often.  (FWIW I don't agree, because if your source tree
is several times larger than your gnulib extract, then it really matters
whether you need to rebuild the world even rarely.)

I proposed using stamp files before, but there are (understandable)
reservations against them.

Cheers,
Ralf

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

[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 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 detail which Make actions would happen that
> doesn't happen now.

Perhaps you thought that a mere "make", even without re-running
`configure', will trigger these rules.  But that is not the case: as
long as config.status is not updated, these rules will not be
triggered, since unistd.h etc. will always be newer than the
corresponding *.in.h templates, due to the fact that move-if-change
_will_ overwrite them with newer versions whenever there's a real
change in the *.in.h templates.

Am I missing something?

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

[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.  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 generated on typical platforms.

Yes.

> 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.  How is my suggestion worse than the current
situation?

> 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 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 detail which Make actions would happen that
doesn't happen now.

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

[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 generated on typical platforms.  And this would occur
every time one does a 'make', even when there's no real work
to do.

The unnecessary "make" actions would fill up people's screens,
and would be confusing.  I'm afraid this cure would be worse
than the disease.

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

[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" would do nothing.  This
> > worked by producing the generated files under temporary names and by
> > using move-if-change to overwrite the old files if the new ones were
> > different.
> 
> If memory serves, that process is pretty error-prone.  One can't
> simply use move-if-change: one needs a separate time stamp file for
> each file that one is doing the move-if-change trick with.  Otherwise,
> when you run 'make' again, it will cheerfully regenerate all the .h
> files again.

Sorry, I don't see the difficulty.  Perhaps I'm missing something.

The current recipe for producing, e.g., unistd.h from unistd.in.h is
this:

  unistd.h: unistd.in.h $(top_builddir)/config.status $(CXXDEFS_H) 
$(ARG_NONNULL_H) $(WARN_ON_USE_H)
  $(AM_V_GEN)rm -f $@-t $@ && \
  { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
sed -e 's|@''GUARD_PREFIX''@|GL|g' \
[...]
-e '/definition of _GL_WARN_ON_USE/r $(WARN_ON_USE_H)'; \
  } > $@-t && \
  mv $@-t $@

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, but as
long as that file isn't copied over unistd.h, the source files that
include unistd.h won't be recompiled.  Regeneration of unistd.h-t is
very fast; it's the needless recompilation of the plethora of source
files that include unistd.h that is the problem addressed by this bug
report.

It could be the case that some configure.in wizardry would resolve
this even nicer, by doing a similar move-if-change trick with
config.status (whose being a prerequisite of these header files is the
trigger for their regeneration, IIUC).  That will prevent even the
regeneration itself.  But I don't know if this is possible without too
much effort, so the suggested simpler "band-aid" is good enough for
me.

> Part of the problem is deciding automatically whether a change is
> one "of essence".

I think comparing the old file with the new one, like move-if-change
does, is all that's needed.  There's no requirement to detect changes
that are non-essential, like comments etc. -- if any change is
detected, let the files be recompiled.  Am I missing something?

Re: new module timer-time

[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, timer_gettime, timer_settime are available in the same
way on all platforms:

libcaix-4.3.2
libcaix-5.1.0
libcaix-5.2.0
libcaix-5.3.0a
libcaix-6.1.0
libcaix-7.1.0
libccygwin-1.5
libccygwin-1.7
librt   glibc-2.3.6
libchpux-10.20
libchpux-11.00
librt   hpux-11.00
libchpux-11.11
librt   hpux-11.11
libchpux-11.23
librt   hpux-11.23
libchpux-11.31
librt   hpux-11.31
libcirix-6.5
libcnetbsd-3.0
libcnetbsd-5.0
libcnetbsd-5.0.1
libcopenbsd-3.8
librt   osf1-4.0d
librt   osf1-5.1a
libposix4   solaris-2.10
librt   solaris-2.10
libcsolaris-2.11_2010_11
libposix4   solaris-2.11_2010_11
librt   solaris-2.11_2010_11
libposix4   solaris-2.5.1
libposix4   solaris-2.6
libposix4   solaris-2.7
librt   solaris-2.7
libposix4   solaris-2.8
librt   solaris-2.8
libposix4   solaris-2.9
librt   solaris-2.9
MISSING in  beos freebsd-5.2.1 freebsd-6.0 freebsd-6.4 interix-3.5 
irix-5.3 macosx-10.3 macosx-10.4 macosx-10.5 mingw nsk-G06 pips solaris-2.4

> +# For a program named, say foo, you should add a line like the following
> +# in the corresponding Makefile.am file:
> +# foo_LDADD = $(LDADD) $(LIB_TIMER_TIME)

This comment is redundant: The 'Link' field in the module specification
also says it.

> +Include:
> +

This looks wrong: Users of these functions must include . So that's
what you need to specify here.

While we are at it: What can  do to define these functions on platforms
that lack it?

Bruno
-- 
In memoriam Paul Schneider 

Re: threadlib and emacs

[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.  Gnulib by-and-large supports a POSIX interface
> in other areas, without having to add in a higher-level gnulib-only
> API and support library.

I agree with that. Nowadays, POSIX threads are more universally supported
than at the time when 'threadlib' was written, and the fact that pthreads-win32
is shipped with mingw-w64 on Cygwin gives it another push.

About a year ago, I already affirmed that it would be good to transform
the {lock,tls,cond,yield,thread} modules to something that provides the
newest POSIX API, supporting other thread APIs under the hood (older pthreads
and Win32 threads being the most important ones). But that refactoring will
take a couple of time and result in a larger pthread.in.h (sure!). (The
pthread_sigmask module alone took me one week to make work portably.)

> > If someone wants to use pselect() in a library, that library may be
> > linked into multithreaded programs. With your patch, the package that
> > provides the library and blindly requests 'pselect' will get a
> > pselect() emulation that is not multithread-safe.
> 
> That's a good point.  So let's omit that patch's change to the
> dependencies (in modules/pthread_sigmask).  That is, Emacs etc. can
> use --avoid=threadlib; the default can continue to drag in threadlib.

Good. Then that's fine with me.

When the proposed rewrite of the thread facilities will have happened,
we may be able to simplify much of the non-threadlib code that you are
adding now. But it's not a show-stopper that has to hold up your work
for Emacs.

> diff --git a/ChangeLog b/ChangeLog
> index a521e9b..8c9851f 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,13 @@
> +2011-07-19  Paul Eggert  
> +
> + pthread_sigmask: assume POSIX threads if not using threadlib
> + * m4/pthread_sigmask.m4 (gl_FUNC_PTHREAD_SIGMASK):
> + Assume POSIX threads only if gl_THREADLIB is not defined.
> + Simplify the calculation of HAVE_PTHREAD_SIGMASK, by initially
> + setting it to 0 if the initial check fails, and setting it to 1
> + if a later, fancier check works; this makes it easier to understand
> + the non-threadlib code.
> +
>  2011-07-16  Paul Eggert  
>  
>   pthread_sigmask: ensure usleep is declared
> diff --git a/m4/pthread_sigmask.m4 b/m4/pthread_sigmask.m4
> index 3803988..4a4901f 100644
> --- a/m4/pthread_sigmask.m4
> +++ b/m4/pthread_sigmask.m4
> @@ -1,4 +1,4 @@
> -# pthread_sigmask.m4 serial 10
> +# pthread_sigmask.m4 serial 12
>  dnl Copyright (C) 2011 Free Software Foundation, Inc.
>  dnl This file is free software; the Free Software Foundation
>  dnl gives unlimited permission to copy and/or distribute it,
> @@ -6,16 +6,21 @@ dnl with or without modifications, as long as this notice 
> is preserved.
>  
>  AC_DEFUN([gl_FUNC_PTHREAD_SIGMASK],
>  [
> -  AC_REQUIRE([gl_THREADLIB])
> -
>AC_CHECK_FUNCS_ONCE([pthread_sigmask])
> +  if test $ac_cv_func_pthread_sigmask != yes; then
> +HAVE_PTHREAD_SIGMASK=0
> +  fi
>LIB_PTHREAD_SIGMASK=
> +
> +  m4_ifdef([gl_[]THREADLIB], [
> +dnl Assume threadlib is in use if its main symbol is defined.
> +dnl Spell the symbol in a funny way, so that aclocal doesn't see it
> +dnl and define it for us even if we don't want it.
> +AC_REQUIRE([gl_[]THREADLIB])
>if test "$gl_threads_api" = posix; then
> -if test $ac_cv_func_pthread_sigmask = yes; then
> -  dnl pthread_sigmask is available without -lpthread.
> -  :
> -else
> -  if test -n "$LIBMULTITHREAD"; then
> +  if test $ac_cv_func_pthread_sigmask != yes &&
> + test -n "$LIBMULTITHREAD"
> +  then
>  AC_CACHE_CHECK([for pthread_sigmask in $LIBMULTITHREAD],
>[gl_cv_func_pthread_sigmask_in_LIBMULTITHREAD],
>[gl_save_LIBS="$LIBS"
> @@ -34,13 +39,8 @@ AC_DEFUN([gl_FUNC_PTHREAD_SIGMASK],
>  if test $gl_cv_func_pthread_sigmask_in_LIBMULTITHREAD = yes; then
>dnl pthread_sigmask is available with -lpthread.
>LIB_PTHREAD_SIGMASK="$LIBMULTITHREAD"
> -else
> -  dnl pthread_sigmask is not available at all.
> -  HAVE_PTHREAD_SIGMASK=0
> +HAVE_PTHREAD_SIGMASK=1
>  fi
> -  else
> -dnl pthread_sigmask is not available at all.
> -HAVE_PTHREAD_SIGMASK=0
>fi
>  fi
>else

Essentially fine with me, except that I prefer a patch that leaves the
if-else chain and the associated comments in place. Your change causes
HAVE_PTHREAD_SIGMASK to be initially 1, then sometimes set to 0, and then
in some cases set back to 1. Which is certainly shorter but not so easy
to understand and (in my opinion) more likely to introduce bugs in the
future.

> @@ -52,10 +52,31 @@ AC

Re: 24.0.50; ./configure causes massive recompilation

[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 by
> using move-if-change to overwrite the old files if the new ones were
> different.

If memory serves, that process is pretty error-prone.  One can't
simply use move-if-change: one needs a separate time stamp file for
each file that one is doing the move-if-change trick with.  Otherwise,
when you run 'make' again, it will cheerfully regenerate all the .h
files again.  And with the time stamp files, one runs into problems
where the time stamp files are out of sync with reality.

I'm not saying it can't be done, but it would be a pain to have it
done without losing reliability during the build.  Part of the problem
is deciding automatically whether a change is one "of essence".

Re: git, merging patches

[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 to do that.

> I have looked through the Stanford tutorial you mentioned and picked up some
> tips.

Many of these tutorials suggest to use branches extensively. Personally I
minimize the use of branches and work almost exclusively with "git stash",
"git commit --amend", and "git rebase -i".

I'm sure Ralf does the opposite and uses branches a lot.

Anyway, what matters is that proposed and committed patches are easy to
review and easy to understand.

> I took the liberty
> of using "diff -w" to generate it, as that makes the diff easier to read.

Very fine. I'll reply to it in another mail.

Bruno
-- 
In memoriam Paul Schneider 

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

[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

[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, errno, _("error in timer_settime"));
> 
> A minor point: the usual (more-conservative, and often-faster) style
> in coreutils is to write "foo (...) != 0" rather than "foo (...) ==
> -1" for system calls that return 0 or -1.
> 
>> We could remove the setitimer stuff altogether and
>> just support 1 second resolution on darwin et. al.
>> That's by far the most common use case anyway.
> 

OK I'll do that, encompassing your fallback suggestion.

> 
>> The gnulib check could be lumped into clock_time, like:
> 
> Yes, that would work, but the clock-time module probably should stay
> decoupled from timer_settime.  How about the following (untested)
> patch instead?  The idea is to append "timeout_LDADD +=
> $(LIB_TIMER_SETTIME)" to src/Makefile.am.
> 
> diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4

I'd rather not add this into jm-macros.
How about just adding a module to gnulib
where others might find it useful too?
Proposed module attached.

cheers,
Pádraig.
>From 40c196b627ab6b5343cabd7fd4befc0733142ba5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Tue, 19 Jul 2011 21:51:49 +0100
Subject: [PATCH] timer-time: A new module to check for timer_settime()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* m4/timer_time.m4: Check for the POSIX function.
* modules/timer-time: Add the new module.
* MODULES.html.sh (Compat checks for POSIX:2008 functions):
Mention it.

Signed-off-by: Pádraig Brady 
---
 ChangeLog  |8 
 MODULES.html.sh|1 +
 m4/timer_time.m4   |   26 ++
 modules/timer-time |   26 ++
 4 files changed, 61 insertions(+), 0 deletions(-)
 create mode 100644 m4/timer_time.m4
 create mode 100644 modules/timer-time

diff --git a/ChangeLog b/ChangeLog
index e72af4c..fa135a2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
 2011-07-19  Pádraig Brady  
 
+	timer-time: A new module to check for timer_settime()
+	* m4/timer_time.m4: Check for the posix function.
+	* modules/timer-time: Add the new module.
+	* MODULES.html.sh (Compat checks for POSIX:2008 functions):
+	Mention it.
+
+2011-07-19  Pádraig Brady  
+
 	getopt-gnu: suppress core dumps from detection code
 	* m4/getopt.m4 (gl_GETOPT_CHECK_HEADERS): Use the nocrash module
 	to suppress core dumps that may well occur on glibc systems.
diff --git a/MODULES.html.sh b/MODULES.html.sh
index 99de344..bcd8aac 100755
--- a/MODULES.html.sh
+++ b/MODULES.html.sh
@@ -2522,6 +2522,7 @@ func_all_modules ()
   func_module link-follow
   func_module rename-dest-slash
   func_module rmdir-errno
+  func_module timer-time
   func_module unlink-busy
   func_module winsz-ioctl
   func_module winsz-termios
diff --git a/m4/timer_time.m4 b/m4/timer_time.m4
new file mode 100644
index 000..29e5a3d
--- /dev/null
+++ b/m4/timer_time.m4
@@ -0,0 +1,26 @@
+# timer_time.m4 serial 1
+dnl Copyright (C) 2011 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+# Check for timer_settime, and set LIB_TIMER_TIME.
+# For a program named, say foo, you should add a line like the following
+# in the corresponding Makefile.am file:
+# foo_LDADD = $(LDADD) $(LIB_TIMER_TIME)
+
+AC_DEFUN([gl_TIMER_TIME],
+[
+  dnl Based on clock_time.m4. See details there.
+
+  AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
+
+  LIB_TIMER_TIME=
+  AC_SUBST([LIB_TIMER_TIME])
+  gl_saved_libs=$LIBS
+AC_SEARCH_LIBS([timer_settime], [rt posix4],
+   [test "$ac_cv_search_timer_settime" = "none required" ||
+LIB_TIMER_TIME=$ac_cv_search_timer_settime])
+AC_CHECK_FUNCS([timer_settime])
+  LIBS=$gl_saved_libs
+])
diff --git a/modules/timer-time b/modules/timer-time
new file mode 100644
index 000..1adcf2c
--- /dev/null
+++ b/modules/timer-time
@@ -0,0 +1,26 @@
+Description:
+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.
+
+Files:
+m4/timer_time.m4
+
+Depends-on:
+extensions
+
+configure.ac:
+gl_TIMER_TIME
+
+Makefile.am:
+
+Include:
+
+Link:
+$(LIB_TIMER_TIME)
+
+License:
+LGPLv2+
+
+Maintainer:
+Pádraig Brady
-- 
1.7.5.2

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

[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 @@
  return result;
  ]])],
  [gl_cv_func_strstr_linear=yes], [gl_cv_func_strstr_linear=no],
-[dnl Only glibc>  2.12 and cygwin>  1.7.7 are known to have a
- dnl bug-free strstr that works in linear time.
+[dnl Only glibc>  2.12 on processors without SSE 4.2 instructions and
+ dnl cygwin>  1.7.7 are known to have a bug-free strstr that works in
+ dnl linear time.



   AC_EGREP_CPP([Lucky user],
 [
  #include
  #ifdef __GNU_LIBRARY__
   #if ((__GLIBC__ == 2&&  __GLIBC_MINOR__>  12) || (__GLIBC__>  2)) \
+&&  !(defined __i386__ || defined __x86_64__) \


Makes sense to me.

--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: strerror_r replaced on linux?

[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 details.

Even with glibc 2.14, where __xpg_strerror_r is finally bug-free, we 
_still_ have to replace strerror_r to get the POSIX signature by default.


Someday, I'd like to add a strerror_r-gnu module, as well as 
guaranteeing that the strerror_r-posix module provides __xpg_strerror_r 
on all platforms while not touching strerror_r if strerror_r-gnu is also 
in use, so that files that must care about the difference (such as 
gnulib internals) can blindly use __xpg_strerror_r, without interfering 
with the user's choice of which signature they'd like to use.  At which 
point, clients of strerror_r-gnu would no longer be replacing strerror_r 
on glibc 2.14 and newer.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

[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 guess.
* m4/strstr.m4 (gl_FUNC_STRSTR): On glibc > 2.12 with x86 or x86_64
CPUs, guess no, in view of glibc
BZ #12100 .
Suggested by Eric Blake. Reported by Reuben Thomas.

--- m4/strstr.m4.orig   Tue Jul 19 23:42:30 2011
+++ m4/strstr.m4Tue Jul 19 23:37:10 2011
@@ -1,4 +1,4 @@
-# strstr.m4 serial 14
+# strstr.m4 serial 15
 dnl Copyright (C) 2008-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -93,13 +93,15 @@
 return result;
 ]])],
 [gl_cv_func_strstr_linear=yes], [gl_cv_func_strstr_linear=no],
-[dnl Only glibc > 2.12 and cygwin > 1.7.7 are known to have a
- dnl bug-free strstr that works in linear time.
+[dnl Only glibc > 2.12 on processors without SSE 4.2 instructions and
+ dnl cygwin > 1.7.7 are known to have a bug-free strstr that works in
+ dnl linear time.
  AC_EGREP_CPP([Lucky user],
[
 #include 
 #ifdef __GNU_LIBRARY__
  #if ((__GLIBC__ == 2 && __GLIBC_MINOR__ > 12) || (__GLIBC__ > 2)) \
+ && !(defined __i386__ || defined __x86_64__) \
  && !defined __UCLIBC__
   Lucky user
  #endif
-- 
In memoriam Paul Schneider 

Re: HAVE_LC_MESSAGES

[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?

[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.org http://palestinefacts.org http://camera.org
A man paints with his brains and not with his hands.

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

[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 and to avoid core dumps.
> 
> Pádraig Brady wrote:
>> Note my Fedora system is configured to include pids in the core files,
> 
> Hence "rm -f core" in a configure test would be wrong. Hmm, is gnulib is
> the only package that has configure tests that may crash, or would it
> be useful to move the 'nocrash' module to Autoconf (in the form of an
> Autoconf built-in)?

That might be useful yes.
Also it might be worth adding core.[0-9]* to the list to delete?

> 
>> Attached.
> 
> Nearly perfect. Just this code here
> 
>  nocrash_init();
> 
>  int result = 0;
> 
> uses C99 features not in C89 (declaration after statement). Swap these, and
> the patch is fine.

Heh, I surprised myself and already caught that.

change now pushed.

cheers,
Pádraig.

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

[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:
> Note my Fedora system is configured to include pids in the core files,

Hence "rm -f core" in a configure test would be wrong. Hmm, is gnulib is
the only package that has configure tests that may crash, or would it
be useful to move the 'nocrash' module to Autoconf (in the form of an
Autoconf built-in)?

> Attached.

Nearly perfect. Just this code here

 nocrash_init();

 int result = 0;

uses C99 features not in C89 (declaration after statement). Swap these, and
the patch is fine.

Bruno
-- 
In memoriam Paul Schneider 

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

[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 5:44 PM, Daniel P. Berrange  
> wrote:
>> 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 is in order to minimize CPU until
>>> >>something interesting happens, where interesting includes needing to
>>> >>wake up a helper thread to do an action inside locks in response to the
>>> >>receipt of a signal.
>>> >>
>>> >>Maybe you are on to something, and replacing all uses of pipe() with
>>> >>virPipeToSelf() (which uses pipe() for efficiency on Linux, but
>>> >>socketpair() on mingw), would allow libvirt to continue to use the
>>> >>pipe-to-self idiom while also using fds that can actually be poll'd on
>>> >>mingw.
>>> >
>>> >IIRC, we never resolved this for the last release. I think we should
>>> >do as you suggest and just use socketpair() on Win32. Given the way
>>> >in which libvirt uses these capabilities, I don't think the overheads
>>> >of socketpair() vs pipe() are so onerous that we need worry about an
>>> >even more fancy Win32 impl or eventfd for linux. Of course if someone
>>> >wants todo a full job for gnulib meawhile, we won't complain...
>>>
>>> Well, right now, we don't even have socketpair() for Win32.  We'd
>>> have to wire up some other native APIs for this to work.
>>
>> Oh I read your mail above as indicating we did have socketpair()
>> on Mingw32. A quick look through google, suggests most people
>> go down the route of creating a TCP socket bound to localhost
>> for this purpose.
>>
>> Daniel
>> --
>> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
>> |: http://libvirt.org              -o-             http://virt-manager.org :|
>> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
>> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
>>
>>
>
/* Copyright (C) 2011 Free Software Foundation, Inc.

   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see .  */

#include 

#include 
/* memset */
#include 
/* close */
#include 


#include 
/* for socket, bind, accept, connect, listen */
#include 
/* getaddrinfo_r */
#include 

#ifndef SOCK_CLOEXEC 
#define  SOCK_CLOEXEC 0
#endif

#if !defined HAVE_SOCKETPAIR || 1

/* fake errno to something allowed by POSIX */
static int
filtererrno (int e)
{
  switch (e)
{
case EAFNOSUPPORT:
case EMFILE:
case ENFILE:
case EOPNOTSUPP:
case EPROTONOSUPPORT:
case EPROTOTYPE:
case EACCES:
case EFAULT:
case ENOBUFS:
case ENOMEM:
  return e;
default:
  return ENOMEM;
}
}

/* filter out supported domain, type, protocol */
static int
socketpairsupported (int domain, int type, int protocol)
{
  (void) type;
  if (type != SOCK_DGRAM && type != SOCK_STREAM 
  && type != SOCK_SEQPACKET && type != 0)
return -1;
  #if HAVE_IPV4
  if (domain == AF_INET)
return AF_INET;
  #endif
  #if HAVE_IPV6
  if(domain == AF_INET6)
return AF_INET6;
  #endif
  #if HAVE_IPV6 || HAVE_IPV4
  if(domain == AF_UNSPEC)
return AF_UNSPEC;
  #endif
  return -1;
}



/* 
   The socketpair() call creates an unnamed pair of connected sockets 
   in the specified domain, 
   of the specified type, and using the optionally specified protocol.

   This function create a socketpair using IPV4/IPV6
*/
static int
raw_socketpair_ipv46 (int domain, int rawtype, int protocol, int sv[2])
{
#if HAVE_IPV6 ||  HAVE_IPV4
  struct sockaddr_storage serverfd_addr, outsock_addr;
  socklen_t addr_len = sizeof (struct sockaddr_storage);
  struct addrinfo hints, *res;
  int getaddrinfo_r;
  int serverfd;
  int saved_errno;
  int insock, outsock;
  int type;
  int cloexecflag;
  int servertype;

  /* filter out cloexec flag */
  cloexecflag = rawtype & SOCK_CLOEXEC;
  cloexecflag = 0; /* socket does not understand cloexec */
  type = rawtype & ~SOCK_CLOEXEC;

  /* filter out protocol */
  if (socketpairsupported (domain, type, protocol) < 0)
 

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

[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 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 interesting includes needing to
>> >>wake up a helper thread to do an action inside locks in response to the
>> >>receipt of a signal.
>> >>
>> >>Maybe you are on to something, and replacing all uses of pipe() with
>> >>virPipeToSelf() (which uses pipe() for efficiency on Linux, but
>> >>socketpair() on mingw), would allow libvirt to continue to use the
>> >>pipe-to-self idiom while also using fds that can actually be poll'd on
>> >>mingw.
>> >
>> >IIRC, we never resolved this for the last release. I think we should
>> >do as you suggest and just use socketpair() on Win32. Given the way
>> >in which libvirt uses these capabilities, I don't think the overheads
>> >of socketpair() vs pipe() are so onerous that we need worry about an
>> >even more fancy Win32 impl or eventfd for linux. Of course if someone
>> >wants todo a full job for gnulib meawhile, we won't complain...
>>
>> Well, right now, we don't even have socketpair() for Win32.  We'd
>> have to wire up some other native APIs for this to work.
>
> Oh I read your mail above as indicating we did have socketpair()
> on Mingw32. A quick look through google, suggests most people
> go down the route of creating a TCP socket bound to localhost
> for this purpose.
>
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
>
>

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

[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 code does not remove those.


But if it improves the
situation, then I'm okay with a patch - would you care to submit one?


Attached.


ACK.  Thanks for doing this.

--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

[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 noticed core files which are due to this I think.
>> Should it be protected with m4/nocrash.m4 ?
> 
> 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 code does not remove those.

> But if it improves the
> situation, then I'm okay with a patch - would you care to submit one?

Attached.

cheers,
Pádraig.
>From 9da91f2716be762ec0d69b0ccc9770faf458cd1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Tue, 19 Jul 2011 17:22:49 +0100
Subject: [PATCH] getopt-gnu: suppress core dumps from detection code
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* m4/getopt.m4 (gl_GETOPT_CHECK_HEADERS): Use the nocrash module
to suppress core dumps that may well occur on glibc systems.
These core dumps might not be cleaned up automatically, or could
trigger some system core dump handling logic.
* modules/getopt-gnu: Depend on nocrash.

Signed-off-by: Pádraig Brady 
---
 ChangeLog  |7 +++
 m4/getopt.m4   |3 +++
 modules/getopt-gnu |1 +
 3 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a521e9b..e72af4c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-07-19  Pádraig Brady  
+
+	getopt-gnu: suppress core dumps from detection code
+	* m4/getopt.m4 (gl_GETOPT_CHECK_HEADERS): Use the nocrash module
+	to suppress core dumps that may well occur on glibc systems.
+	* modules/getopt-gnu: Depend on nocrash.
+
 2011-07-16  Paul Eggert  
 
 	pthread_sigmask: ensure usleep is declared
diff --git a/m4/getopt.m4 b/m4/getopt.m4
index 7e49ddd..c7de83d 100644
--- a/m4/getopt.m4
+++ b/m4/getopt.m4
@@ -231,7 +231,10 @@ dnl is ambiguous with environment values that contain newlines.
 [AC_LANG_PROGRAM([[#include 
#include 
#include 
+   ]GL_NOCRASH[
]], [[
+ nocrash_init();
+
  int result = 0;
  /* This code succeeds on glibc 2.8, OpenBSD 4.0, Cygwin, mingw,
 and fails on MacOS X 10.5, AIX 5.2, HP-UX 11, IRIX 6.5,
diff --git a/modules/getopt-gnu b/modules/getopt-gnu
index 3e5876a..6ad3643 100644
--- a/modules/getopt-gnu
+++ b/modules/getopt-gnu
@@ -5,6 +5,7 @@ process command line arguments.
 Files:
 
 Depends-on:
+nocrash
 getopt-posix
 
 configure.ac:
-- 
1.7.5.2

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

[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 142, i.e. 128 + 14,
i.e. the 5-second alarm has fired. I have a 2.5GHz i5 Sandy Bridge
CPU.


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



memmem is on the other hand diagnosed as linear on my system.


Yep - because memmem isn't "optimized" for small strings.

The _real_ fix would be to write a patch that uses hueristics - SSE4.2 
for short needles and linear algorithm for long needles (the SSE4.2 
optimizations are indeed faster for short needles, but scale 
quadratically; for large needles, using SSE4.2 doesn't provide quite the 
speedups).  But it takes time to write not only the patch, but also the 
timing programs that will definitively prove that we are not pessimizing 
speed over a large set of inputs (short vs. long needles, repetitive vs. 
unique needles, SSE4.2 vs. older chip, ...).


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

[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 interesting includes needing to
wake up a helper thread to do an action inside locks in response to the
receipt of a signal.

Maybe you are on to something, and replacing all uses of pipe() with
virPipeToSelf() (which uses pipe() for efficiency on Linux, but
socketpair() on mingw), would allow libvirt to continue to use the
pipe-to-self idiom while also using fds that can actually be poll'd on
mingw.


IIRC, we never resolved this for the last release. I think we should
do as you suggest and just use socketpair() on Win32. Given the way
in which libvirt uses these capabilities, I don't think the overheads
of socketpair() vs pipe() are so onerous that we need worry about an
even more fancy Win32 impl or eventfd for linux. Of course if someone
wants todo a full job for gnulib meawhile, we won't complain...


Well, right now, we don't even have socketpair() for Win32.  We'd have 
to wire up some other native APIs for this to work.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

[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 is in order to minimize CPU until
> >>something interesting happens, where interesting includes needing to
> >>wake up a helper thread to do an action inside locks in response to the
> >>receipt of a signal.
> >>
> >>Maybe you are on to something, and replacing all uses of pipe() with
> >>virPipeToSelf() (which uses pipe() for efficiency on Linux, but
> >>socketpair() on mingw), would allow libvirt to continue to use the
> >>pipe-to-self idiom while also using fds that can actually be poll'd on
> >>mingw.
> >
> >IIRC, we never resolved this for the last release. I think we should
> >do as you suggest and just use socketpair() on Win32. Given the way
> >in which libvirt uses these capabilities, I don't think the overheads
> >of socketpair() vs pipe() are so onerous that we need worry about an
> >even more fancy Win32 impl or eventfd for linux. Of course if someone
> >wants todo a full job for gnulib meawhile, we won't complain...
> 
> Well, right now, we don't even have socketpair() for Win32.  We'd
> have to wire up some other native APIs for this to work.

Oh I read your mail above as indicating we did have socketpair()
on Mingw32. A quick look through google, suggests most people
go down the route of creating a TCP socket bound to localhost
for this purpose.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Re: Is the module unused-parameter incomplete?

[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 in gnulib/NEWS 
on 2011-07-12.




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 named
in 'bootstrap.conf'.


The bug is in inetutils' bootstrap.conf, for trying to update to a newer 
gnulib version without updating the module names to match.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

strstr is linear test fails on my machine with glibc 2.13

[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 fired. I have a 2.5GHz i5 Sandy Bridge
CPU.

memmem is on the other hand diagnosed as linear on my system.

-- 
http://rrt.sc3d.org

Re: HAVE_LC_MESSAGES

[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 libintl.h already defines LC_MESSAGES 
>>> > when
>>> > needed, and clisp uses libintl.h.
>>> 
>>> CLISP includes libintl.h only if ENABLE_NLS is defined (i.e., when
>>> gettext is present).
>>> It uses HAVE_LC_MESSAGES in spvw_ctype.d:init_ctype which is called
>>> unconditionally in spvw.d.
>>> I.e., on platforms without gettext where LC_MESSAGES is not defined
>>> init_ctype is still called and its call
>>> 
>>>   setlocale(LC_MESSAGES,"");
>>> 
>>> must be guarded by either "#if HAVE_LC_MESSAGES" or "#ifdef LC_MESSAGES".
>>
>> By looking at the clisp code history:
>>   $ hg annotate -r 11858 spvw_ctype.d
>>   $ hg diff -r 3562 -r 3563
>> I think the point was to allow the setlocale() call to be enabled even on
>> platforms where  does not have LC_MESSAGES (namely, native 
>> Windows).
>> The macro HAVE_LC_MESSAGES means
>>   - on Unix platforms, that LC_MESSAGES was found in ,
>>   - on Windows platforms, that gettext is in use (always).
>
> what are the benefits of this very complex approach (autoconf, win32 &c &c)
> over a simple "ifdef LC_MESSAGES"?
>
>> I think you can remove the #if because all Unix platforms nowadays have
>> LC_MESSAGES.
>
> what about windows without gettext?

also, can I now remove gt_LC_MESSAGES from configure.in?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://www.memritv.org http://openvotingconsortium.org
http://truepeace.org http://iris.org.il http://camera.org http://ffii.org
If at first you don't suck seed, try and suck another seed.

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

[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 be protected with m4/nocrash.m4 ?


Does nocrash.m4 prevent core files on Linux, or is it just for 
preventing modal popup boxes on other OS?  But if it improves the 
situation, then I'm okay with a patch - would you care to submit one?


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

[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 doesn't work on pipes. It doesn't
> >> actually wait but just returns immediately. Digging MSDN and googling
> >> about this suggest that there is no simple solution to this.
> > 
> > Yes, Windows pipes are that broken. :(
> > 
> > Using socketpair is a possibly good idea, but I would do it on
> > libvirtd only.  I don't know exactly how libvirtd uses this pipe, but
> > perhaps it can be changed to an eventfd-like abstraction that can be
> > used with both Windows and Unix.  This is similar to Eric's
> > suggestion, but without the pipe at all.  It would also be a
> > libvirtd-specific suggestion.
> 
> 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 interesting includes needing to
> wake up a helper thread to do an action inside locks in response to the
> receipt of a signal.
> 
> Maybe you are on to something, and replacing all uses of pipe() with
> virPipeToSelf() (which uses pipe() for efficiency on Linux, but
> socketpair() on mingw), would allow libvirt to continue to use the
> pipe-to-self idiom while also using fds that can actually be poll'd on
> mingw.

IIRC, we never resolved this for the last release. I think we should
do as you suggest and just use socketpair() on Win32. Given the way
in which libvirt uses these capabilities, I don't think the overheads
of socketpair() vs pipe() are so onerous that we need worry about an
even more fancy Win32 impl or eventfd for linux. Of course if someone
wants todo a full job for gnulib meawhile, we won't complain...

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

Is the module unused-parameter incomplete?

[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 named
in 'bootstrap.conf'. To me it seems as if the locations

   build-aux/snippet/unused-parameter.h
   modules/snippet/unused-parameter'

be the main culprits in this issue. Vacation prevents me from
getting support from my project compatriots just now, so forgive
my naive guessing!

Best regards,
  Mats E Andersson, on behalf of GNU Inetutils

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

[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,
Pádraig.

Re: git, merging patches

[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 using "diff -w" to generate it, as that makes the diff easier to read.
If you prefer it in glorious whitespace-expanded form I can generate that too.

diff --git a/ChangeLog b/ChangeLog
index a521e9b..8c9851f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2011-07-19  Paul Eggert  
+
+   pthread_sigmask: assume POSIX threads if not using threadlib
+   * m4/pthread_sigmask.m4 (gl_FUNC_PTHREAD_SIGMASK):
+   Assume POSIX threads only if gl_THREADLIB is not defined.
+   Simplify the calculation of HAVE_PTHREAD_SIGMASK, by initially
+   setting it to 0 if the initial check fails, and setting it to 1
+   if a later, fancier check works; this makes it easier to understand
+   the non-threadlib code.
+
 2011-07-16  Paul Eggert  
 
pthread_sigmask: ensure usleep is declared
diff --git a/m4/pthread_sigmask.m4 b/m4/pthread_sigmask.m4
index 3803988..4a4901f 100644
--- a/m4/pthread_sigmask.m4
+++ b/m4/pthread_sigmask.m4
@@ -1,4 +1,4 @@
-# pthread_sigmask.m4 serial 10
+# pthread_sigmask.m4 serial 12
 dnl Copyright (C) 2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -6,16 +6,21 @@ dnl with or without modifications, as long as this notice is 
preserved.
 
 AC_DEFUN([gl_FUNC_PTHREAD_SIGMASK],
 [
-  AC_REQUIRE([gl_THREADLIB])
-
   AC_CHECK_FUNCS_ONCE([pthread_sigmask])
+  if test $ac_cv_func_pthread_sigmask != yes; then
+HAVE_PTHREAD_SIGMASK=0
+  fi
   LIB_PTHREAD_SIGMASK=
+
+  m4_ifdef([gl_[]THREADLIB], [
+dnl Assume threadlib is in use if its main symbol is defined.
+dnl Spell the symbol in a funny way, so that aclocal doesn't see it
+dnl and define it for us even if we don't want it.
+AC_REQUIRE([gl_[]THREADLIB])
   if test "$gl_threads_api" = posix; then
-if test $ac_cv_func_pthread_sigmask = yes; then
-  dnl pthread_sigmask is available without -lpthread.
-  :
-else
-  if test -n "$LIBMULTITHREAD"; then
+  if test $ac_cv_func_pthread_sigmask != yes &&
+ test -n "$LIBMULTITHREAD"
+  then
 AC_CACHE_CHECK([for pthread_sigmask in $LIBMULTITHREAD],
   [gl_cv_func_pthread_sigmask_in_LIBMULTITHREAD],
   [gl_save_LIBS="$LIBS"
@@ -34,13 +39,8 @@ AC_DEFUN([gl_FUNC_PTHREAD_SIGMASK],
 if test $gl_cv_func_pthread_sigmask_in_LIBMULTITHREAD = yes; then
   dnl pthread_sigmask is available with -lpthread.
   LIB_PTHREAD_SIGMASK="$LIBMULTITHREAD"
-else
-  dnl pthread_sigmask is not available at all.
-  HAVE_PTHREAD_SIGMASK=0
+HAVE_PTHREAD_SIGMASK=1
 fi
-  else
-dnl pthread_sigmask is not available at all.
-HAVE_PTHREAD_SIGMASK=0
   fi
 fi
   else
@@ -52,10 +52,31 @@ AC_DEFUN([gl_FUNC_PTHREAD_SIGMASK],
 dnl link dependencies.
 if test $ac_cv_func_pthread_sigmask = yes; then
   REPLACE_PTHREAD_SIGMASK=1
-else
-  HAVE_PTHREAD_SIGMASK=0
 fi
   fi
+  ],[
+dnl Assume threadlib is not in use.
+dnl Assume POSIX.1-2008 (or later) semantics.  Do not fiddle with
+dnl compiler or linker options, since any application not
+dnl already properly configured for threads is most likely single
+dnl threaded and can use gnulib's sigprocmask-based substitute.
+if test $ac_cv_func_pthread_sigmask = yes; then
+  AC_CACHE_CHECK([for pthread_sigmask with POSIX signature],
+[gl_cv_func_pthread_sigmask_posix_signature],
+[AC_LINK_IFELSE(
+   [AC_LANG_PROGRAM(
+  [[#include 
+  ]],
+  [[return pthread_sigmask (0, (sigset_t *) 0, (sigset_t *) 0);]])
+   ],
+   [gl_cv_func_pthread_sigmask_posix_signature=yes],
+   [gl_cv_func_pthread_sigmask_posix_signature=no])])
+  if test "$gl_cv_func_pthread_sigmask_posix_signature" != yes; then
+REPLACE_PTHREAD_SIGMASK=1
+  fi
+fi
+  ])
+
   AC_SUBST([LIB_PTHREAD_SIGMASK])
   dnl We don't need a variable LTLIB_PTHREAD_SIGMASK, because when
   dnl "$gl_threads_api" = posix, $LTLIBMULTITHREAD and $LIBMULTITHREAD are the

Re: git, merging patches

[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

[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 would be;
but it does not mean that the patch I've proposed (which is simple and
which works for Emacs), is worse than what we have already (which does
not work for Emacs).

That comment's point (1b) was addressed in the the more recent patch,
as it does not use gl_AVOID_MODULE_x.

That comment's point (2) is the claim that the changes are useful only
for Emacs.  I've written about that claim at some length.  You don't
agree with my assessment, but that does not mean that I didn't address
the point.

Gnulib should be flexible enough to support different styles of usage
with a minimum of overhead and complexity.  It shouldn't insist on a
particular programming model.  It's fine that Gnulib supports
threadlib, but Gnulib shouldn't insist on threadlib as opposed to
POSIX threads.

> coreutils-8.12 contains threadlib.m4 and invokes gl_THREADLIB
> from configure. I haven't seen reports that it is causing harm.

As I understand it, coreutils drags in threadlib only by accident (for
the tests) and threadlib is not used in the coreutils applications
proper.  If we could break unnecessary dependencies (a common problem
with gnulib, unfortunately, and not just for threads), coreutils
wouldn't use threadlib at all.

> If someone wants to use pselect() in a library, that library may be
> linked into multithreaded programs. With your patch, the package that
> provides the library and blindly requests 'pselect' will get a
> pselect() emulation that is not multithread-safe.

That's a good point.  So let's omit that patch's change to the
dependencies (in modules/pthread_sigmask).  That is, Emacs etc. can
use --avoid=threadlib; the default can continue to drag in threadlib.

Surely this removes your major objection to the patch.  The revised
patch won't change behavior at all, unless an application explicitly
says --avoid=threadlib.

> many applications make use of POSIX threads, without
> using gnulib, or using gnulib but not threadlib.m4. But they do
> so at the price of
>   - having lots of platform dependent code (gcc), or
>   - turning off POSIX threads on some older platforms (coreutils
> 'sort', for example), or
>   - having portability bugs.

It's the second category we're talking about here.

> I don't really understand your objections against threadlib.m4,
> outside of Emacs. Of course it is not simple code, but is that
> enough of an argument to discard it entirely?

Yes, I'm afraid so.  I'd rather not take the time to understand
another thread library interface, support it in applications I help
maintain, and explain it to others.

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.  Gnulib by-and-large supports a POSIX interface
in other areas, without having to add in a higher-level gnulib-only
API and support library.  There's no fundamental reason it can't do
the same thing for simple things like pselect.

> I don't see coreutils - with a modern autoconf infrastructure - and
> emacs - with a case-by-case configure.in - in the same boat here, at all.

In some ways they are different, yes.  The sense that I was talking
about is that they both use just POSIX threads, and do not need
porting to Solaris threads etc.  Also, for both packages it's unlikely
that I could convince their maintainers to use a non-POSIX thread
interface even if I thought it was a good idea.