Re: double inclusion guard

[Gary V. Vaughan]

Hi Sam, Bruno,

On 12 Oct 2010, at 08:39, Gary V. Vaughan wrote:
> On 12 Oct 2010, at 06:17, Bruno Haible wrote:
 You probably renamed the inclusion guard (_GL_STDLIB_H)
 appropriate (as recommended).
>>> 
>>> does this "as recommended" mean that you are now more amenable to
>>> accepting my patch?
>>> http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/gnulib-tool.patch?view=log
>> 
>> The fact that you have been testing this approach for a year and have 
>> reported
>> just this one problem with it gives it some trust. Also Bruce Korb's libposix
>> needs a similar treatment.
> 
> I was just homing in on a similar patch myself, after struggling to write a
> post-install hook sed script that will rewrite the include guards without
> accidentally catching and rewriting other random _GL_ prefixed symbols.

Actually, this patch is quite broken.  It happily rewrites *all* _GL_
symbols for files copied to $libdir, but it doesn't fix up headers that
come from gnulib/build-aux, so *references* to macros defined there get
rewritten, but not the definitions.  Also it doesn't rewrite any of the
Makefile.am snippets from module files that rely on sed scripts keyed
to the original _GL_ symbols (e.g. the c++defs.h include machinery).

> This patch (or similar) would certainly make libposix much cleaner too.

I think that all we needed was a way of rewriting the include guards, and
that rewriting every symbol containing _GL_ is much too heavy handed.  I'm
working on a gentler version of the patch that only matches the include
guards.

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

PGP.sig
Description: This is a digitally signed message part

Re: double inclusion guard

[Bruce Korb]

On 10/11/10 20:18, Gary V. Vaughan wrote:
> Then I believe the only viable option to provide stable support
> for multiple gnulib directories in a single tree is to add a
> switch to gnulib-tool to rewrite gnulib #include_next lines
> on import, so that both types of compilers include header
> files in the same order.  It's certainly doable, but it's
> going to be finicky and easy to break.
> 
> I believe this is the problem Bruce was thinking about

Precisely.

> (and which I dismissed prematurely.. sorry Bruce!) with
> symbols in installed gnulib headers from libposix clashing
> with non-libposix gnulib headers in a gnulib client project
> that also uses libposix... perhaps more patches like Bruno's
> patch from earlier in this thread will also be required.

Blech.  KISS:  once you've included a gnulib mumble.h, all other
gnulib mumble.h-es are noop-ed.  OK, so it is theoretically possible
for the contents to vary based on how the installing package
gets configured.  If that's a problem, don't use libposix because
it is not clear how you choose which is authoritative.  If someone
really, really wants libposix and uses gnulib modules that pull in
duplicate posix headers, then you have just become a volunteer
to walk through the mine field to help show the way. :)

So for now, I recommend *not* fiddling multi-inclusion guards,
though I will do it because I said I would.  I recommend against.

Cheers - Bruce

Re: double inclusion guard

[Gary V. Vaughan]

Hi Eric,

On 12 Oct 2010, at 08:54, Eric Blake wrote:
> On 10/11/2010 07:39 PM, Gary V. Vaughan wrote:
>> There are only two options to make both cases behave the same -
>> 
>>   1. always hardcode the full path to the system header, even on machines
>>  with include_next support;
> 
> (1) is not viable.  If a system header itself uses include_next, then we MUST 
> include that header via system_include, or the nested include_next tries to 
> include the same absolute name (itself) instead of its intended target.  
> That's why we had to start using include_next throughout gnulib in the first 
> place.

Yuck :(

Then I believe the only viable option to provide stable support for multiple 
gnulib directories in a single tree is to add a switch to gnulib-tool to 
rewrite gnulib #include_next lines on import, so that both types of compilers 
include header files in the same order.  It's certainly doable, but it's going 
to be finicky and easy to break.

I believe this is the problem Bruce was thinking about (and which I dismissed 
prematurely.. sorry Bruce!) with symbols in installed gnulib headers from 
libposix clashing with non-libposix gnulib headers in a gnulib client project 
that also uses libposix... perhaps more patches like Bruno's patch from earlier 
in this thread will also be required.

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

PGP.sig
Description: This is a digitally signed message part

Re: double inclusion guard

[Eric Blake]

On 10/11/2010 07:39 PM, Gary V. Vaughan wrote:

There are only two options to make both cases behave the same -

   1. always hardcode the full path to the system header, even on machines
  with include_next support;


(1) is not viable.  If a system header itself uses include_next, then we 
MUST include that header via system_include, or the nested include_next 
tries to include the same absolute name (itself) instead of its intended 
target.  That's why we had to start using include_next throughout gnulib 
in the first place.


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

Re: double inclusion guard

[Gary V. Vaughan]

Hi Sam, Bruno,

On 12 Oct 2010, at 06:17, Bruno Haible wrote:
>>> You probably renamed the inclusion guard (_GL_STDLIB_H)
>>> appropriate (as recommended).
>> 
>> does this "as recommended" mean that you are now more amenable to
>> accepting my patch?
>> http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/gnulib-tool.patch?view=log
> 
> The fact that you have been testing this approach for a year and have reported
> just this one problem with it gives it some trust. Also Bruce Korb's libposix
> needs a similar treatment.

I was just homing in on a similar patch myself, after struggling to write a
post-install hook sed script that will rewrite the include guards without
accidentally catching and rewriting other random _GL_ prefixed symbols.

This patch (or similar) would certainly make libposix much cleaner too.

> But I'm wondering whether we might see different behaviours when using 
> compilers
> which support #include_next and other compilers which don't. When you have two
> gnulib-generated files
> 
>  main/gllib/stdlib.h
>  extra/gllib/stdlib.h
> 
> and the compiler options include "-Iextra/gllib -Imain/gllib", then
> with compilers of the first kind the program will include
> 
>  extra/gllib/stdlib.h -> main/gllib/stdlib.h -> /usr/include/stdlib.h
> 
> whereas with compilers of the second kind the program will include
> 
>  extra/gllib/stdlib.h -> /usr/include/stdlib.h
> 
> Such differences would be very hard to diagnose when they lead to problems.
> Any ideas?

There are only two options to make both cases behave the same -

  1. always hardcode the full path to the system header, even on machines
 with include_next support;
  2. teach gnulib to generate full include paths to another gnulib directory
 under some circumstances (i.e. when importing to extra/glib, set an
 option to write include paths that point to main/gllib.

(2) seems fragile and is more difficult to implement, so the general solution
must be to not use include_next.

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

PGP.sig
Description: This is a digitally signed message part

Re: [PATCH] bootstrap: add hook for altering gnulib.mk, for Bison

[Gary V. Vaughan]

Hi Paul,

On 12 Oct 2010, at 00:12, Paul Eggert wrote:
> On 10/11/10 05:28, Gary V. Vaughan wrote:
> 
>> Ping?
> 
> I just now looked at it, and my goodness, there are a lot of changes.
> I don't get the big picture: why are the changes being made?  Perhaps
> you could briefly discuss that?

Thanks.

Well, there are only 2 changes, removing the old bootstrap, and then
rewriting it from scratch as an entirely new file.

The problem was that the incumbent bootstrap is a poorly commented
accretion of ad-hoc changes accumulated as other packages have adopted
it.  There's no clear separation of concerns, and it's hard to read
it and see what's required to incorporate it into a new project.

As we (various denizens of bug-gnulib, not you and I particularly)
discussed previously, the idea of this brand new script is to be a
fully commented, fully general, easily extensible bootstrap script
to work well with existing users, and share code that is genuinely
general and useful to other packages without accreting hacks tuned
for particular packages.

As I've tweaked it to support existing users, I've found that some
of them (bison and tar, I'm looking at you!) don't even use the
canonical version... and have some bespoke changes in bootstrap itself
as well as a custom bootstrap.conf.

Also, the giant slurp() function, which I found particularly difficult
to digest, seems no longer necessary in light of the changes to gnulib
since it was written.  I was keen to modernise and decompose the
functionality to make it as easy as possible to override the parts
that don't apply to the adopting project at hand, without having to
rewrite swathes of code.

The huge docu-comment at the head of the script describes how I
envision using it.

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)


PGP.sig
Description: This is a digitally signed message part

Re: [PATCH] bootstrap: add hook for altering gnulib.mk, for Bison

[Gary V. Vaughan]

Hi Eric,

On 12 Oct 2010, at 03:24, Eric Blake wrote:
> On 10/08/2010 10:15 PM, Gary V. Vaughan wrote:
>> Please find attached: bootstrap itself, and matching bootstrap.conf
>> files for m4, libtool and coreutils resp. (using master as at 2 weeks
>> ago or thereabouts).
> 
> Rather than one giant change for bootstrap, could you post it as a series of 
> incremental git commits that does one thing at a time?  It makes reviewing 
> much easier when it is distilled to logical changes, rather than viewing it 
> as a complete overhaul.

Not really, because the change was:

$ rm bootstrap
$ emacs bootstrap
**HACK HACK HACK**
^X^S
**TEST TEST TEST**
**HACK HACK HACK**
^X^C
$ mail bootstrap

If you don't feel confident with an entirely new bootstrap script without more 
proof that it is working properly (which I totally understand), I'll have time 
to finish the remaining bootstrap.conf files in a month or so, and will repost 
then.

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

PGP.sig
Description: This is a digitally signed message part

Re: double inclusion guard

[Bruno Haible]

Hi Sam,

> > You probably renamed the inclusion guard (_GL_STDLIB_H)
> > appropriate (as recommended).
> 
> does this "as recommended" mean that you are now more amenable to
> accepting my patch?
> http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/gnulib-tool.patch?view=log

The fact that you have been testing this approach for a year and have reported
just this one problem with it gives it some trust. Also Bruce Korb's libposix
needs a similar treatment.

But I'm wondering whether we might see different behaviours when using compilers
which support #include_next and other compilers which don't. When you have two
gnulib-generated files

  main/gllib/stdlib.h
  extra/gllib/stdlib.h

and the compiler options include "-Iextra/gllib -Imain/gllib", then
with compilers of the first kind the program will include

  extra/gllib/stdlib.h -> main/gllib/stdlib.h -> /usr/include/stdlib.h

whereas with compilers of the second kind the program will include

  extra/gllib/stdlib.h -> /usr/include/stdlib.h

Such differences would be very hard to diagnose when they lead to problems.
Any ideas?

Bruno

Re: module request: gmalloc

[Bruno Haible]

Hi Sam,

> some platforms have malloc implementations with extra features like 
> randomizations, and some applications cannot handle those features.
> thus emacs (and clisp) come with gmalloc.c by Mike Haertel.
> It would be nice if it were offered by gnulib

Generally one should use the malloc() from the system. It's better integrated
with the rest of the system (for example, on Linux is uses the 'mremap' system
call). The reasons for using GNU malloc depend on the system.

I guess Emacs uses it on all platforms, because of 'unexec'.

For clisp, the "makemake --help" says it's needed on HP-UX and OpenBSD. On
HP-UX it is needed because otherwise clisp crashes; I could never really
determine whether it is HP-UX malloc which is buggy or whether the reason is
simply that gmalloc is more forgiving (it survives out-of-range memory writes
more often). For OpenBSD, I don't know or remember the reasons. But in any
case, address space randomization is something applications need to get
friendly with, because it's not going away (given the flood of malware
attacks out there).

So, I don't see how to make a gnulib module out of it, that includes an
autoconf macro that would be suitable for both Emacs and clisp.

Bruno

Re: error: redefinition of `struct random_data'

[Sam Steingold]

Hi Bruno,

On Mon, Oct 11, 2010 at 6:41 PM, Bruno Haible  wrote:
>
> It sounds like you have two invocations for gnulib-tool, one for gllib,
> and one for regexp/gllib.

you must be clairvoyant.

> You probably renamed the inclusion guard (_GL_STDLIB_H)
> appropriate (as recommended).

does this "as recommended" mean that you are now more amenable to
accepting my patch?
http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/gnulib-tool.patch?view=log

> I think the problem you encountered is not specific to clisp, therefore I'm
> applying approach a).

thanks.

-- 
Sam Steingold 

Re: error: redefinition of `struct random_data'

[Bruno Haible]

Hi Sam,

> I am getting this error 
> when compiling gllib in the regexp clisp module on mingw and cygwin:
> gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I/.../current/modules/regexp/gllib -I.. 
> -I/.../top/include -I/.../current/build-mingw-g-7/gllib 
> -I/.../current/build-mingw-g-7  -g -O2 -W -Wswitch -Wcomment -Wpointer-arith 
> -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare 
> -Wno-format-nonliteral -falign-functions=4 -D_WIN32 -g -O0 -DDEBUG_OS_ERROR 
> -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE 
> -DNO_TERMCAP_NCURSES 
> -DDYNAMIC_FFI -DDYNAMIC_MODULES -DNO_GETTEXT -I.  -DDLL_EXPORT -DPIC 
> -I/.../current/build-mingw-g-7/  -MT malloc.o -MD -MP -MF .deps/malloc.Tpo -c 
> -o malloc.o /.../current/modules/regexp/gllib/malloc.c
> In file included from /.../current/modules/regexp/gllib/malloc.c:
> 32:./stdlib.h:65: error: redefinition of `struct random_data'
> make[4]: *** [malloc.o] Error 1
> 
> indeed, I have stdlib.h both in gllib and regexp/gllib.

It sounds like you have two invocations for gnulib-tool, one for gllib,
and one for regexp/gllib. During the configurations, it was determined that
the system's  does not define 'struct random_data', so it is
gnulib's task to define it. So both generated stdlib.h files now define
'struct random_data'. Now, in your compilation the -I options refer to
both directories where they exist, hence the #include_next statements
chain the two files. You probably renamed the inclusion guard (_GL_STDLIB_H)
appropriate (as recommended). And now the two structure definitions clash.

There are two ways out:
  a) gnulib should add another guard so as to ensure that 'struct random_data'
 does not get defined twice.
  b) You use the gnulib-tool option --avoid-stdlib in regexp/gllib.

I think the problem you encountered is not specific to clisp, therefore I'm
applying approach a).


2010-10-11  Bruno Haible  

stdlib: Allow multiple gnulib generated replacements to coexist.
* lib/stdlib.in.h (struct random_data): Avoid identical redefinition.
Reported by Sam Steingold .

--- a/lib/stdlib.in.h
+++ b/lib/stdlib.in.h
@@ -61,6 +61,9 @@
 #endif
 
 #if !...@have_struct_random_data@
+/* Define 'struct random_data'.
+   But allow multiple gnulib generated  replacements to coexist.  */
+# if !GNULIB_defined_struct_random_data
 struct random_data
 {
   int32_t *fptr;/* Front pointer.  */
@@ -71,6 +74,8 @@ struct random_data
   int rand_sep; /* Distance between front and rear.  */
   int32_t *end_ptr; /* Pointer behind state table.  */
 };
+#  define GNULIB_defined_struct_random_data 1
+# endif
 #endif
 
 #if (@GNULIB_MKSTEMP@ || @GNULIB_GETSUBOPT@ || defined GNULIB_POSIXCHECK) && ! 
defined __GLIBC__ && !((defined _WIN32 || defined __WIN32__) && ! defined 
__CYGWIN__)

module request: gmalloc

[Sam Steingold]

some platforms have malloc implementations with extra features like 
randomizations, and some applications cannot handle those features.

thus emacs (and clisp) come with gmalloc.c by Mike Haertel.
It would be nice if it were offered by gnulib, so that I won't have to have my 
own special login to handle the --with-gmalloc configure option and could 
instead get the gmalloc module from gnulib and --with-included-malloc (???) 
would DTRT.

thanks.
Sam.

error: redefinition of `struct random_data'

[Sam Steingold]

All of a sudden (after the 27-Sep-10 sync with gnulib) I am getting this error 
when compiling gllib in the regexp clisp module on mingw and cygwin:
gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I/.../current/modules/regexp/gllib -I.. 
-I/.../top/include -I/.../current/build-mingw-g-7/gllib 
-I/.../current/build-mingw-g-7  -g -O2 -W -Wswitch -Wcomment -Wpointer-arith 
-Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare 
-Wno-format-nonliteral -falign-functions=4 -D_WIN32 -g -O0 -DDEBUG_OS_ERROR 
-DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DNO_TERMCAP_NCURSES 
-DDYNAMIC_FFI -DDYNAMIC_MODULES -DNO_GETTEXT -I.  -DDLL_EXPORT -DPIC 
-I/.../current/build-mingw-g-7/  -MT malloc.o -MD -MP -MF .deps/malloc.Tpo -c 
-o malloc.o /.../current/modules/regexp/gllib/malloc.c

In file included from /.../current/modules/regexp/gllib/malloc.c:
32:./stdlib.h:65: error: redefinition of `struct random_data'
make[4]: *** [malloc.o] Error 1

indeed, I have stdlib.h both in gllib and regexp/gllib.
what has happened?
thanks.
Sam.

Re: [PATCH] futimens: work around Solaris 11 bug

[Jim Meyering]

Eric Blake wrote:
> Revert "test-futimens: avoid unwarranted test failure on Solaris 5.11"
> This reverts commit 0afab138f4aedb7eaab70957c164aa0e5eb01fce.
>
> * m4/futimens.m4 (gl_FUNC_FUTIMENS): Detect the bug.
> * tests/test-futimens.h (test_futimens): Enhance, rather than
> weaken test.
> * doc/posix-functions/futimens.texi (futimens): Document the bug.
>
> Signed-off-by: Eric Blake 
> ---
>
>> > We already worked around this bug for glibc 2.11
>> > (thankfully, it has been fixed for current glibc).
>> That makes sense.  You're welcome to revert this once the .m4
>> and wrapper machinery renders it unnecessary.
>
> Done.
>
>  ChangeLog |   15 ---
>  doc/posix-functions/futimens.texi |4 
>  m4/futimens.m4|   13 -
>  tests/test-futimens.h |3 +++
>  4 files changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index 60c0d76..5aaee75 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,11 @@
> +2010-10-11  Eric Blake  
> +
> + futimens: work around Solaris 11 bug
> + * m4/futimens.m4 (gl_FUNC_FUTIMENS): Detect the bug.
> + * tests/test-futimens.h (test_futimens): Enhance, rather than
> + weaken test.
> + * doc/posix-functions/futimens.texi (futimens): Document the bug.
> +
>  2010-10-11  Paul Eggert  
>
>   Indentation.
> diff --git a/doc/posix-functions/futimens.texi 
> b/doc/posix-functions/futimens.texi
> index be4698a..7c35b8b 100644
> --- a/doc/posix-functions/futimens.texi
> +++ b/doc/posix-functions/futimens.texi
> @@ -28,6 +28,10 @@ futimens
>  When using @code{UTIME_OMIT} for the modification time, but specifying
>  an access time, some systems fail to update the change time:
>  Linux kernel 2.6.32.
> +...@itme

Thanks for the quick work.
I fixed that typo.

Re: [PATCH] bootstrap: add hook for altering gnulib.mk, for Bison

[Eric Blake]

On 10/08/2010 10:15 PM, Gary V. Vaughan wrote:

Please find attached: bootstrap itself, and matching bootstrap.conf
files for m4, libtool and coreutils resp. (using master as at 2 weeks
ago or thereabouts).


Rather than one giant change for bootstrap, could you post it as a 
series of incremental git commits that does one thing at a time?  It 
makes reviewing much easier when it is distilled to logical changes, 
rather than viewing it as a complete overhaul.


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

[PATCH] futimens: work around Solaris 11 bug

[Eric Blake]

Revert "test-futimens: avoid unwarranted test failure on Solaris 5.11"
This reverts commit 0afab138f4aedb7eaab70957c164aa0e5eb01fce.

* m4/futimens.m4 (gl_FUNC_FUTIMENS): Detect the bug.
* tests/test-futimens.h (test_futimens): Enhance, rather than
weaken test.
* doc/posix-functions/futimens.texi (futimens): Document the bug.

Signed-off-by: Eric Blake 
---

> > We already worked around this bug for glibc 2.11
> > (thankfully, it has been fixed for current glibc).
> That makes sense.  You're welcome to revert this once the .m4
> and wrapper machinery renders it unnecessary.

Done.

 ChangeLog |   15 ---
 doc/posix-functions/futimens.texi |4 
 m4/futimens.m4|   13 -
 tests/test-futimens.h |3 +++
 4 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 60c0d76..5aaee75 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2010-10-11  Eric Blake  
+
+   futimens: work around Solaris 11 bug
+   * m4/futimens.m4 (gl_FUNC_FUTIMENS): Detect the bug.
+   * tests/test-futimens.h (test_futimens): Enhance, rather than
+   weaken test.
+   * doc/posix-functions/futimens.texi (futimens): Document the bug.
+
 2010-10-11  Paul Eggert  

Indentation.
diff --git a/doc/posix-functions/futimens.texi 
b/doc/posix-functions/futimens.texi
index be4698a..7c35b8b 100644
--- a/doc/posix-functions/futimens.texi
+++ b/doc/posix-functions/futimens.texi
@@ -28,6 +28,10 @@ futimens
 When using @code{UTIME_OMIT} for the modification time, but specifying
 an access time, some systems fail to update the change time:
 Linux kernel 2.6.32.
+...@itme
+Passing @code{AT_FDCWD} as the fd argument does not properly fail with
+...@code{ebadf} on some systems:
+glibc 2.11, Solaris 11.
 @end itemize

 Portability problems not fixed by Gnulib:
diff --git a/m4/futimens.m4 b/m4/futimens.m4
index 255010c..1212fb9 100644
--- a/m4/futimens.m4
+++ b/m4/futimens.m4
@@ -1,4 +1,4 @@
-# serial 4
+# serial 5
 # See if we need to provide futimens replacement.

 dnl Copyright (C) 2009, 2010 Free Software Foundation, Inc.
@@ -23,18 +23,21 @@ AC_DEFUN([gl_FUNC_FUTIMENS],
 #include 
 #include 
 #include 
+#include 
 ]], [[struct timespec ts[2] = { { 1, UTIME_OMIT }, { 1, UTIME_NOW } };
   int fd = creat ("conftest.file", 0600);
   struct stat st;
   if (fd < 0) return 1;
+  errno = 0;
   if (futimens (AT_FDCWD, NULL) == 0) return 2;
-  if (futimens (fd, ts)) return 3;
+  if (errno != EBADF) return 3;
+  if (futimens (fd, ts)) return 4;
   sleep (1);
   ts[0].tv_nsec = UTIME_NOW;
   ts[1].tv_nsec = UTIME_OMIT;
-  if (futimens (fd, ts)) return 4;
-  if (fstat (fd, &st)) return 5;
-  if (st.st_ctime < st.st_atime) return 6;
+  if (futimens (fd, ts)) return 5;
+  if (fstat (fd, &st)) return 6;
+  if (st.st_ctime < st.st_atime) return 7;
   ]])],
 dnl FIXME: simplify this in 2012, when file system bugs are no longer common
  [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
diff --git a/tests/test-futimens.h b/tests/test-futimens.h
index a0312b7..3a6d1da 100644
--- a/tests/test-futimens.h
+++ b/tests/test-futimens.h
@@ -75,6 +75,9 @@ test_futimens (int (*func) (int, struct timespec const *),

   /* Invalid arguments.  */
   errno = 0;
+  ASSERT (func (AT_FDCWD, NULL) == -1);
+  ASSERT (errno == EBADF);
+  errno = 0;
   ASSERT (func (-1, NULL) == -1);
   ASSERT (errno == EBADF);
   {
-- 
1.7.2.3

Re: [PATCH] test-futimens: avoid unwarranted test failure on Solaris 5.11

[Jim Meyering]

Eric Blake wrote:
> On 10/11/2010 04:51 AM, Jim Meyering wrote:
>> That's because futimens (AT_FDCWD, NULL) would fail with errno set to
>> EFAULT, rather than the expected value of EBADF.
>>
>> At first I was going to relax the test to allow "|| errno == EFAULT",
>> but what if EFAULT is not defined?  There's only one other use in gnulib.
>
> I agree that we should not relax things for EFAULT.
>
>> +++ b/tests/test-futimens.h
>> @@ -75,7 +75,7 @@ test_futimens (int (*func) (int, struct timespec const *),
>>
>> /* Invalid arguments.  */
>> errno = 0;
>> -  ASSERT (func (AT_FDCWD, NULL) == -1);
>> +  ASSERT (func (-1, NULL) == -1);
>
> However, I disagree with this change.  The whole point of testing
> AT_FDCWD is that it IS an invalid fd, and implementations must reject
> it in a sane manner.  Solaris 5.11 has a bug, and we need to enhance
> the .m4 test to reject this bug and improve our futimens wrapper to
> work around it.  We already worked around this bug for glibc 2.11
> (thankfully, it has been fixed for current glibc).

That makes sense.  You're welcome to revert this once the .m4
and wrapper machinery renders it unnecessary.

Re: [PATCH] Fix mismatched parens in previous commit

[Paul Eggert]

On 10/11/10 01:05, Gary V. Vaughan wrote:
> Pushed as an obvious fix to rebalance parentheses.

Thanks, and sorry about that.  I didn't catch it because coreutils doesn't
use that .h file.  I originally messed up the parentheses partly because
the code was using a non-GNU indenting style:

((FOO
  & BAR) == 0)

and I didn't notice the "== 0".
The code should use this style to lessen confusion:

((FOO
  & BAR)
 == 0)

so I pushed this further patch.

>From 4615288b60c104efbb98a8165f13263f6ef46a3d Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 11 Oct 2010 10:49:52 -0700
Subject: [PATCH] Indentation.

* lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap): Indent
higher-level operators more to the left.
---
 ChangeLog  |6 ++
 lib/spawn.in.h |3 ++-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 22a22df..60c0d76 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-10-11  Paul Eggert  
+
+   Indentation.
+   * lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap): Indent
+   higher-level operators more to the left.
+
 2010-10-11  Jim Meyering  
 
test-futimens: avoid unwarranted test failure on Solaris 5.11
diff --git a/lib/spawn.in.h b/lib/spawn.in.h
index 39d6507..26c3c10 100644
--- a/lib/spawn.in.h
+++ b/lib/spawn.in.h
@@ -150,7 +150,8 @@ typedef int verify_POSIX_SPAWN_USEVFORK_no_overlap
 [(((POSIX_SPAWN_RESETIDS | POSIX_SPAWN_SETPGROUP
 | POSIX_SPAWN_SETSIGDEF | POSIX_SPAWN_SETSIGMASK
 | POSIX_SPAWN_SETSCHEDPARAM | POSIX_SPAWN_SETSCHEDULER)
-   & POSIX_SPAWN_USEVFORK) == 0)
+   & POSIX_SPAWN_USEVFORK)
+  == 0)
  ? 1 : -1];
 
 
-- 
1.7.2

pkg-config (was: installable gnulib library)

[Ralf Wildenhues]

Hello Gary,

* Gary V. Vaughan wrote on Mon, Oct 11, 2010 at 09:31:55AM CEST:
> On 9 Oct 2010, at 22:40, Bruce Korb wrote:
> >> I think I know why pkg-config makes autotools people wince...
> >> 
> >> 
> >> I still regret not having noticed pkg-config before it became so pervasive 
> >> -
> >> it basically repeats all of the work libtool already did, and then ignores
> >> a few critically important parts, so that if you use any kind of directory
> > 
> > I submit that it isn't completely too late.  Add a LT_CREATE_PKG_CONFIG
> > configure macro that spits out a .pc file named after the AC_INIT-named
> > package.  How hard can that be?  (I am *not* volunteering)
> > However, you are certainly right about that PKG_CONFIG_PATH thing.
> > /etc/sysconfig/pkgconfig would have been very useful.
> 
> It is the .pc files that are the problem actually.

No.  The files themselves are fairly innocent actually.  It's that they
are used wrongly, and the pkg-config semantics aren't right.

> libtool already contains most of the information that pkg-config wants,

But libtool doesn't, and cannot, deal with per-package preprocess and
compile flags.  Trying to make it do so is bad design.

Even the inherited_linker_flags are, in hindsight, not well designed.
Sure, -pthread needs to be used for dependent packages, but it needs
to be used at compile time already, not just at link time.  And passing
it on precludes building a dependent package with a different compiler
that spells -pthread differently (both of these have happened to me, by
the way).  The right thing would have been a system- and
compiler-independent wrapper option that translates to the right opton.

> and
> it is much smarter about looking for deplips along the library search path
> without requiring the manual maintenance of *another* path for a tool that
> doesn't know it's way around the library search path.

Granted, but it has its warts as well.

> The right solution would be to make sure that the .la files include any
> additional details required to provide the output that pkg-config users are
> chasing, and to add a mode to the libtool script to extract and display it.

But the number of packages using .pc files is much larger than those
using libtool.  Unless you are going for vendor lock-in strategy, it's
not a decent idea to consider that .pc files are going away.

Cheers,
Ralf

Re: [PATCH] bootstrap: add hook for altering gnulib.mk, for Bison

[Paul Eggert]

On 10/11/10 05:28, Gary V. Vaughan wrote:

> Ping?

I just now looked at it, and my goodness, there are a lot of changes.
I don't get the big picture: why are the changes being made?  Perhaps
you could briefly discuss that?

Re: installable gnulib library

[Eric Blake]

On 10/10/2010 08:19 PM, Gary V. Vaughan wrote:

The common way to get rid of these warnings is to insert an invocation of
gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.


Seems like a kludge to me.  Either the AC_{RUN,COMPILE}_IFELSE using modules
should AC_REQUIRE_ONCE([gl_USE_SYSTEM_EXTENSIONS]) themselves, or AC_{RUN,
COMPILE}_IFELSE should invoke the require rather than the warning, no?  And
if that doesn't work, then AC_REQUIRE is not outputting macro expansions in
the right order.

What's the difference between AC_USE_SYSTEM_EXTENSIONS and gl_USE_SYSTEM_
EXTENSIONS?  The warnings seem to indicate that adding AC_REQUIRE([AC_
USE_SYSTEM_EXTENSIONS]) to AC_{RUN,COMPILE}_IFELSE is the right solution.


AC_RUN_IFELSE must NOT require AC_USE_SYSTEM_EXTENSIONS - the whole 
point of having them as separate macros is that it MUST be possible to 
write a project that conforms to strict C89 and does not require the use 
of AC_USE_SYSTEM_EXTENSIONS.  Rather, what needs to be fixed is the 
notion that _if_ you use AC_USE_SYSTEM_EXTENSIONS, then its use must 
precede AC_RUN_IFELSE.  And right now, there is a known bug in AC_BEFORE 
(which is the mechanism for enforcing this order), which when that bug 
is fixed, starts failing the AC_USE_SYSTEM_EXTENSIONS testsuite in 
autoconf.  Therefore, there is probably an upstream bug in autoconf's 
AC_USE_SYSTEM_EXTENSIONS that is not generating correctly ordered output.


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

possible USE_SYSTEM_EXTENSIONS bug [was: installable gnulib library]

[Eric Blake]

[adding bug-autoconf]

On 10/10/2010 11:02 PM, Gary V. Vaughan wrote:

Hi Bruce,

On 10 Oct 2010, at 22:26, Bruce Korb wrote:

The common way to get rid of these warnings is to insert an invocation of
gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.


Could you explicitly define "appropriate place" in the sample above? :)
I took a guess, based upon the configure.ac generated by the original
"gnulib-tool" invocation.


AC_USE_SYSTEM_EXTENSIONS right after AC_INIT can't fail to patch over
the bug, unless AC_REQUIRE ordering is badly botched.


AC_USE_SYSTEM_EXTENSIONS may still have upstream bugs, even in autoconf 
2.68.  Why do I say this?  Because my pending patch [1] to fix some 
brokenness in AC_BEFORE makes the autoconf testsuite fail its 
AC_USE_SYSTEM_EXTENSIONS test.  I still need to investigate why, and 
whether the gnulib variant gl_USE_SYSTEM_EXTENSIONS is likewise affected.


[1] http://lists.gnu.org/archive/html/bug-autoconf/2010-09/msg00061.html

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

Re: cooperating with pkg-config (was: installable gnulib library

[Gary V. Vaughan]

Hi Bruce,

On 11 Oct 2010, at 22:10, Bruce Korb wrote:
> On Mon, Oct 11, 2010 at 12:31 AM, Gary V. Vaughan wrote:
>> libtool already contains most of the information that pkg-config wants,
> 
> Yep.  And rather than what would likely be a futile fight to
> migrate from ``pkg-config --cflags libname'' to ``libtool
> --show=cflags libname''
> (or something), just say, "fine.  Here's a script to emit libname.pc for you."
> Alternatively, you could provide a patch to pkg-config to look for the .la
> files based upon /etc/ld.so.conf and cause it to exec libtool to process it.
> Erode the thing by making the .la files more convenient than .pc files.
> (Not very hard to do.likely not today tho)
> 
>>  No .pc files required.
> 
> Less client hassle is _always_ better.
> 
>>  No PKG_CONFIG_PATH required.
> 
> YES!!!
> 
>> Much much easier to use and maintain for all involved... pity
>> about all the man years wasted on pkg-config :(
> 
> Indeed.  Still, it's better erode its usefulness than to try to push it aside,
> I think anyway.  So, first, fiddle libtool to emit the data found in .la files
> then provide a pkg-config patch that uses the libtool functionality.
> Whether they accept it or not, eventually ``libtool --show'' would likely
> win out.  Let's do this in all our copious spare time..

I'll add it to my TODO under libtool-3.0 :)

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

PGP.sig
Description: This is a digitally signed message part

Re: cooperating with pkg-config (was: installable gnulib library

[Bruce Korb]

Hi Gary,

On Mon, Oct 11, 2010 at 12:31 AM, Gary V. Vaughan wrote:
> It is the .pc files that are the problem actually.

Yes.  I understand.  It is a nuisance to find them on a system.

> libtool already contains most of the information that pkg-config wants,

Yep.  And rather than what would likely be a futile fight to
migrate from ``pkg-config --cflags libname'' to ``libtool
--show=cflags libname''
(or something), just say, "fine.  Here's a script to emit libname.pc for you."
Alternatively, you could provide a patch to pkg-config to look for the .la
files based upon /etc/ld.so.conf and cause it to exec libtool to process it.
Erode the thing by making the .la files more convenient than .pc files.
(Not very hard to do.likely not today tho)

>  No .pc files required.

Less client hassle is _always_ better.

>  No PKG_CONFIG_PATH required.

YES!!!

> Much much easier to use and maintain for all involved... pity
> about all the man years wasted on pkg-config :(

Indeed.  Still, it's better erode its usefulness than to try to push it aside,
I think anyway.  So, first, fiddle libtool to emit the data found in .la files
then provide a pkg-config patch that uses the libtool functionality.
Whether they accept it or not, eventually ``libtool --show'' would likely
win out.  Let's do this in all our copious spare time..

 - Bruce

Re: libposix - is it done yet?

[Bruce Korb]

Hi Gary, Ralf,

On Sun, Oct 10, 2010 at 11:34 PM, Gary V. Vaughan wrote:er.
>
> Agreed, with some caveats.
>
> Since this affects many gnulib modules, libposix or not:
>
> --- a/modules/stdlib
> +++ b/modules/stdlib
> @@ -18,6 +18,7 @@ configure.ac:
>  gl_STDLIB_H
>
>  Makefile.am
> +noinst_HEADERS += stdlib.h
>  BUILT_SOURCES += stdlib.h

> This also makes the 'Makefile.am:' section of the module files more
> expressive, since you can now express whether a file is a built source
> or not, independently of whether it's a header (that libposix or others
> might wish to install). Surely it's just a fluke that BUILT_SOURCES is
> currently the same set as the headers that libposix wants to install -
> at least for the modules it includes, I haven't looked at the others.

How about "iconv_open" module?  That looks, at first glance,
to be more interesting than the rest.



Makefile.am:
iconv_open-aix.h: iconv_open-aix.gperf
$(GPERF) -m 10 $(srcdir)/iconv_open-aix.gperf > 
$(srcdir)/iconv_open-aix.h-t
mv $(srcdir)/iconv_open-aix.h-t $(srcdir)/iconv_open-aix.h
iconv_open-hpux.h: iconv_open-hpux.gperf
$(GPERF) -m 10 $(srcdir)/iconv_open-hpux.gperf > 
$(srcdir)/iconv_open-hpux.h-t
mv $(srcdir)/iconv_open-hpux.h-t $(srcdir)/iconv_open-hpux.h
iconv_open-irix.h: iconv_open-irix.gperf
$(GPERF) -m 10 $(srcdir)/iconv_open-irix.gperf > 
$(srcdir)/iconv_open-irix.h-t
mv $(srcdir)/iconv_open-irix.h-t $(srcdir)/iconv_open-irix.h
iconv_open-osf.h: iconv_open-osf.gperf
$(GPERF) -m 10 $(srcdir)/iconv_open-osf.gperf > 
$(srcdir)/iconv_open-osf.h-t
mv $(srcdir)/iconv_open-osf.h-t $(srcdir)/iconv_open-osf.h
iconv_open-solaris.h: iconv_open-solaris.gperf
$(GPERF) -m 10 $(srcdir)/iconv_open-solaris.gperf >
$(srcdir)/iconv_open-solaris.h-t
mv $(srcdir)/iconv_open-solaris.h-t $(srcdir)/iconv_open-solaris.h
BUILT_SOURCES+= iconv_open-aix.h iconv_open-hpux.h
iconv_open-irix.h iconv_open-osf.h iconv_open-solaris.h
MOSTLYCLEANFILES += iconv_open-aix.h-t iconv_open-hpux.h-t
iconv_open-irix.h-t iconv_open-osf.h-t iconv_open-solaris.h-t
MAINTAINERCLEANFILES += iconv_open-aix.h iconv_open-hpux.h
iconv_open-irix.h iconv_open-osf.h iconv_open-solaris.h
EXTRA_DIST   += iconv_open-aix.h iconv_open-hpux.h
iconv_open-irix.h iconv_open-osf.h iconv_open-solaris.h

Re: [PATCH] bootstrap: add hook for altering gnulib.mk, for Bison

[Gary V. Vaughan]

On 9 Oct 2010, at 11:15, Gary V. Vaughan wrote:
> Seeing the renewed interest in patching the gnulib bootstrap script,
> and how I won't have time for at least a couple of weeks to finish
> my planned bootstrap.conf rewrite for as many bootstrap using GNU
> projects as I could lay my hands on... now seems like as good a time
> as any to post the current state of my rewrite of bootstrap.
> 
> Please find attached: bootstrap itself, and matching bootstrap.conf
> files for m4, libtool and coreutils resp. (using master as at 2 weeks
> ago or thereabouts).
> 
> The huge string at the top of the bootstrap script is slated for
> inclusion in the appropriate texi documentation upon acceptance.
> 
> Feedback welcome.  Permission to push the bootstrap rewrite on gnulib
> master even more welcome!

Ping?

FTR it works as is with coreutils, libtool and m4 with the bootstrap.conf
files attached to my previous post in this thread.

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)


PGP.sig
Description: This is a digitally signed message part

Re: [PATCH] test-futimens: avoid unwarranted test failure on Solaris 5.11

[Eric Blake]

On 10/11/2010 04:51 AM, Jim Meyering wrote:

That's because futimens (AT_FDCWD, NULL) would fail with errno set to
EFAULT, rather than the expected value of EBADF.

At first I was going to relax the test to allow "|| errno == EFAULT",
but what if EFAULT is not defined?  There's only one other use in gnulib.


I agree that we should not relax things for EFAULT.


+++ b/tests/test-futimens.h
@@ -75,7 +75,7 @@ test_futimens (int (*func) (int, struct timespec const *),

/* Invalid arguments.  */
errno = 0;
-  ASSERT (func (AT_FDCWD, NULL) == -1);
+  ASSERT (func (-1, NULL) == -1);


However, I disagree with this change.  The whole point of testing 
AT_FDCWD is that it IS an invalid fd, and implementations must reject it 
in a sane manner.  Solaris 5.11 has a bug, and we need to enhance the 
.m4 test to reject this bug and improve our futimens wrapper to work 
around it.  We already worked around this bug for glibc 2.11 
(thankfully, it has been fixed for current glibc).


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

[PATCH] test-futimens: avoid unwarranted test failure on Solaris 5.11

[Jim Meyering]

There was one gnulib test failure (via coreutils) on Solaris 5.11:

FAIL: test-futimens (exit: 262)
===
test-futimens.h:81: assertion failed

That's because futimens (AT_FDCWD, NULL) would fail with errno set to
EFAULT, rather than the expected value of EBADF.

At first I was going to relax the test to allow "|| errno == EFAULT",
but what if EFAULT is not defined?  There's only one other use in gnulib.
Besides, since we're expecting EBADF, it makes sense to use a more
precisely targeted test.  Less chance that some other implementation will
interpret things differently.

>From 0afab138f4aedb7eaab70957c164aa0e5eb01fce Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Mon, 11 Oct 2010 12:44:56 +0200
Subject: [PATCH] test-futimens: avoid unwarranted test failure on Solaris 5.11

* tests/test-futimens.h (test_futimens): When provoking EBADF, use an
invalid file descriptor, so we don't provoke EFAULT from Solaris 5.11,
because it tries to dereference the NULL name argument.
---
 ChangeLog |7 +++
 tests/test-futimens.h |2 +-
 2 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2f0f370..22a22df 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2010-10-11  Jim Meyering  
+
+   test-futimens: avoid unwarranted test failure on Solaris 5.11
+   * tests/test-futimens.h (test_futimens): When provoking EBADF, use an
+   invalid file descriptor, so we don't provoke EFAULT from Solaris 5.11,
+   because it tries to dereference the NULL name argument.
+
 2010-10-11  Bruno Haible  

Indentation.
diff --git a/tests/test-futimens.h b/tests/test-futimens.h
index ab86ae2..a0312b7 100644
--- a/tests/test-futimens.h
+++ b/tests/test-futimens.h
@@ -75,7 +75,7 @@ test_futimens (int (*func) (int, struct timespec const *),

   /* Invalid arguments.  */
   errno = 0;
-  ASSERT (func (AT_FDCWD, NULL) == -1);
+  ASSERT (func (-1, NULL) == -1);
   ASSERT (errno == EBADF);
   {
 struct timespec ts[2] = { { Y2K, UTIME_BOGUS_POS }, { Y2K, 0 } };
--
1.7.3.1.104.gc752e

Re: [PATCH] Fix mismatched parens in previous commit

[Jim Meyering]

Gary V. Vaughan wrote:
> Pushed as an obvious fix to rebalance parentheses.
>
> * lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap): Fix mismatched
> parens.
> ---
>  ChangeLog  |6 ++
>  lib/spawn.in.h |2 +-
>  2 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index 6a56a31..d32d173 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,9 @@
> +2010-10-11  Gary V. Vaughan  
> +
> + Fix mismatched parens in previous commit
> + * lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap): Fix 
> mismatched
> + parens.

Thanks for the quick fix.
When feasible, please list the name of the affected
module or file name at the beginning of the one-line summary.
(i.e., when only one or a few are affected)
That makes it easier to know what's affected solely from the summary.

spawn.in.h: fix mismatched parens in previous commit


The added parenthesis in your correction made it so the
continued lines were no longer properly indented.
I've fixed that with this additional change:
  
>From 2adeeb98ba9c3a10f0a63dd65a6f5d726ce55802 Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Mon, 11 Oct 2010 10:17:12 +0200
Subject: [PATCH] spawn.in.h: make indentation consistent with parentheses

* lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap):
Make indentation consistent with parentheses.
---
 ChangeLog  |6 ++
 lib/spawn.in.h |6 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 9b0372d..1f5fd32 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-10-11  Jim Meyering  
+
+   spawn.in.h: make indentation consistent with parentheses
+   * lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap):
+   Make indentation consistent with parentheses.
+
 2010-10-11  Gary V. Vaughan  

Fix mismatched parens in previous commit
diff --git a/lib/spawn.in.h b/lib/spawn.in.h
index d49ea6b..44bc110 100644
--- a/lib/spawn.in.h
+++ b/lib/spawn.in.h
@@ -148,9 +148,9 @@ typedef struct
+ 1)
 typedef int verify_POSIX_SPAWN_USEVFORK_no_overlap
  [(((POSIX_SPAWN_RESETIDS | POSIX_SPAWN_SETPGROUP
-| POSIX_SPAWN_SETSIGDEF | POSIX_SPAWN_SETSIGMASK
-| POSIX_SPAWN_SETSCHEDPARAM | POSIX_SPAWN_SETSCHEDULER)
-   & POSIX_SPAWN_USEVFORK) == 0)
+ | POSIX_SPAWN_SETSIGDEF | POSIX_SPAWN_SETSIGMASK
+ | POSIX_SPAWN_SETSCHEDPARAM | POSIX_SPAWN_SETSCHEDULER)
+& POSIX_SPAWN_USEVFORK) == 0)
   ? 1 : -1];


-- 
1.7.3.1.104.gc752e

Re: [PATCH] Fix mismatched parens in previous commit

[Gary V. Vaughan]

On 11 Oct 2010, at 15:21, Jim Meyering wrote:
> Gary V. Vaughan wrote:
>> 
>> +++ b/ChangeLog
>> @@ -1,3 +1,9 @@
>> +2010-10-11  Gary V. Vaughan  
>> +
>> +Fix mismatched parens in previous commit
>> +* lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap): Fix 
>> mismatched
>> +parens.
> 
> Thanks for the quick fix.
> When feasible, please list the name of the affected
> module or file name at the beginning of the one-line summary.
> (i.e., when only one or a few are affected)
> That makes it easier to know what's affected solely from the summary.
> 
>spawn.in.h: fix mismatched parens in previous commit

Okay, sorry.

> The added parenthesis in your correction made it so the
> continued lines were no longer properly indented.
> I've fixed that [[...]]

Thanks.

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

PGP.sig
Description: This is a digitally signed message part

[PATCH] Fix mismatched parens in previous commit

[Gary V. Vaughan]

Pushed as an obvious fix to rebalance parentheses.

* lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap): Fix mismatched
parens.
---
 ChangeLog  |6 ++
 lib/spawn.in.h |2 +-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 6a56a31..d32d173 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-10-11  Gary V. Vaughan  
+
+   Fix mismatched parens in previous commit
+   * lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap): Fix 
mismatched
+   parens.
+
 2010-10-10  Paul Eggert  
 
prefer (X ? 1 : -1) when converting from boolean (1,0) to int (1,-1)
diff --git a/lib/spawn.in.h b/lib/spawn.in.h
index 543475b..d49ea6b 100644
--- a/lib/spawn.in.h
+++ b/lib/spawn.in.h
@@ -147,7 +147,7 @@ typedef struct
 | (POSIX_SPAWN_SETSCHEDULER > 0 ? POSIX_SPAWN_SETSCHEDULER - 1 : 0))  \
+ 1)
 typedef int verify_POSIX_SPAWN_USEVFORK_no_overlap
- [((POSIX_SPAWN_RESETIDS | POSIX_SPAWN_SETPGROUP
+ [(((POSIX_SPAWN_RESETIDS | POSIX_SPAWN_SETPGROUP
 | POSIX_SPAWN_SETSIGDEF | POSIX_SPAWN_SETSIGMASK
 | POSIX_SPAWN_SETSCHEDPARAM | POSIX_SPAWN_SETSCHEDULER)
& POSIX_SPAWN_USEVFORK) == 0)
-- 
1.7.3

Re: installable gnulib library

[Gary V. Vaughan]

Hi Bruce,

On 9 Oct 2010, at 22:40, Bruce Korb wrote:
>> I think I know why pkg-config makes autotools people wince...
>> 
>> 
>> I still regret not having noticed pkg-config before it became so pervasive -
>> it basically repeats all of the work libtool already did, and then ignores
>> a few critically important parts, so that if you use any kind of directory
> 
> I submit that it isn't completely too late.  Add a LT_CREATE_PKG_CONFIG
> configure macro that spits out a .pc file named after the AC_INIT-named
> package.  How hard can that be?  (I am *not* volunteering)
> However, you are certainly right about that PKG_CONFIG_PATH thing.
> /etc/sysconfig/pkgconfig would have been very useful.

It is the .pc files that are the problem actually.

libtool already contains most of the information that pkg-config wants, and
it is much smarter about looking for deplips along the library search path
without requiring the manual maintenance of *another* path for a tool that
doesn't know it's way around the library search path.

The right solution would be to make sure that the .la files include any
additional details required to provide the output that pkg-config users are
chasing, and to add a mode to the libtool script to extract and display it.

No pkg-config tool required.  No .pc files required.  No PKG_CONFIG_PATH
required. Much much easier to use and maintain for all involved... pity
about all the man years wasted on pkg-config :(

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

PGP.sig
Description: This is a digitally signed message part