Re: NetBSD 5.0’s lacks AI_* macros

[Simon Josefsson]

l...@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> NetBSD 5.0’s  doesn’t define ‘AI_ALL’, ‘AI_V4MAPPED’, and
> ‘AI_ADDRCONFIG’.  This can be worked around with something like this:
>
>   #ifndef AI_ALL
>   # define AI_ALL 0
>   #endif
>   #ifndef AI_V4MAPPED
>   # define AI_V4MAPPED 0
>   #endif
>   #ifndef AI_ADDRCONFIG
>   # define AI_ADDRCONFIG 0
>   #endif

Thanks, fixed as below.  Note that _support_ for these symbols is not
required by POSIX (it is conditional on IPv6 support), but the symbols
are required to be defined.  So this is a bug in NetBSD netdb.h and
should be reported.

/Simon

>From be51f2652b95b8b7b8778039c012d0c9c70741a0 Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Wed, 17 Feb 2010 09:19:03 +0100
Subject: [PATCH] netdb.h: Define AI_V4MAPPED, AI_ALL, AI_ADDRCONFIG when needed.

---
 ChangeLog  |6 ++
 lib/netdb.in.h |   28 +---
 2 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 1609f87..b3d0853 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-02-17  Simon Josefsson  
+
+   * lib/netdb.in.h (AI_V4MAPPED, AI_ALL, AI_ADDRCONFIG): Define to 0
+   if not provided by the system's netdb.h.  Reported by
+   l...@gnu.org (Ludovic Courtès).
+
 2010-02-15  Jim Meyering  
 
maint.mk: mark syntax-check sc_*.m rules as .PHONY
diff --git a/lib/netdb.in.h b/lib/netdb.in.h
index 6f3695b..def9b5f 100644
--- a/lib/netdb.in.h
+++ b/lib/netdb.in.h
@@ -74,18 +74,24 @@ struct addrinfo
 # endif
 
 # if 0
-/* The commented out definitions below are not yet implemented in the
-   GNULIB getaddrinfo() replacement, so are not yet needed and may, in fact,
-   cause conflicts on systems with a getaddrinfo() function which does not
-   define them.
-
-   If they are restored, be sure to protect the definitions with #ifndef.  */
 #  define AI_NUMERICHOST0x0004  /* Don't use name resolution.  */
-#  define AI_V4MAPPED   0x0008  /* IPv4 mapped addresses are acceptable.  */
-#  define AI_ALL0x0010  /* Return IPv4 mapped and IPv6 
addresses.  */
-#  define AI_ADDRCONFIG 0x0020  /* Use configuration of this host to choose
-   returned address type..  */
-# endif /* 0 */
+# endif
+
+/* These symbolic constants are required to be present by POSIX, but
+   our getaddrinfo replacement doesn't use them (yet).  Setting them
+   to 0 on systems that doesn't have them avoids causing problems for
+   system getaddrinfo implementations that would be confused by
+   unknown values.  */
+# ifndef AI_V4MAPPED
+#  define AI_V4MAPPED0 /* 0x0008: IPv4 mapped addresses are acceptable.  */
+# endif
+# ifndef AI_ALL
+#  define AI_ALL 0 /* 0x0010: Return IPv4 mapped and IPv6 addresses. */
+# endif
+# ifndef AI_ADDRCONFIG
+#  define AI_ADDRCONFIG  0 /* 0x0020: Use configuration of this host to choose
+  returned address type..  */
+# endif
 
 /* Error values for `getaddrinfo' function.  */
 # ifndef EAI_BADFLAGS
-- 
1.6.6.1

Re: NetBSD 5.0’s lacks AI_* macros

[Ludovic Courtès]

Hi,

Simon Josefsson  writes:

> Thanks, fixed as below.  Note that _support_ for these symbols is not
> required by POSIX (it is conditional on IPv6 support), but the symbols
> are required to be defined.  So this is a bug in NetBSD netdb.h and
> should be reported.

Right.  Thanks!

Ludo’.

Re: userspec-tests: cygwin link failure due to missing -lintl

[Eric Blake]

According to Simon Josefsson on 2/16/2010 11:27 AM:
> ../gllib/libgnu.a(error.o): In function `print_errno_message':
> /home/Simon/gnulib/build/gllib/error.c:153: undefined reference to 
> `_libintl_gettext'
> collect2: ld returned 1 exit status
> make[3]: *** [test-userspec.exe] Error 1
> 
> I'll commit the patch below unless anyone objects.

Looks correct to me.  Go ahead.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net



signature.asc
Description: OpenPGP digital signature

Re: NetBSD 5.0’s lacks AI_* macr os

[Eric Blake]

According to Simon Josefsson on 2/17/2010 1:27 AM:
> Thanks, fixed as below.  Note that _support_ for these symbols is not
> required by POSIX (it is conditional on IPv6 support), but the symbols
> are required to be defined.

> +#  define AI_ADDRCONFIG  0 /* 0x0020: Use configuration of this host to 
> choose
> +  returned address type..  */

Comment typo: s/\.\././

-- 
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net



signature.asc
Description: OpenPGP digital signature

Re: userspec-tests: cygwin link failure due to missing -lintl

[Simon Josefsson]

Eric Blake  writes:

> According to Simon Josefsson on 2/16/2010 11:27 AM:
>> ../gllib/libgnu.a(error.o): In function `print_errno_message':
>> /home/Simon/gnulib/build/gllib/error.c:153: undefined reference to 
>> `_libintl_gettext'
>> collect2: ld returned 1 exit status
>> make[3]: *** [test-userspec.exe] Error 1
>> 
>> I'll commit the patch below unless anyone objects.
>
> Looks correct to me.  Go ahead.

Done, thanks for review it.

/Simon

Re: NetBSD 5.0’s lacks AI_* macros

[Simon Josefsson]

Eric Blake  writes:

> According to Simon Josefsson on 2/17/2010 1:27 AM:
>> Thanks, fixed as below.  Note that _support_ for these symbols is not
>> required by POSIX (it is conditional on IPv6 support), but the symbols
>> are required to be defined.
>
>> +#  define AI_ADDRCONFIG  0 /* 0x0020: Use configuration of this host to 
>> choose
>> +  returned address type..  */
>
> Comment typo: s/\.\././

Fixed, thanks!

/Simon

Re: userspec-tests: cygwin link failure due to missing -lintl

[Jim Meyering]

Simon Josefsson wrote:

> Eric Blake  writes:
>
>> According to Simon Josefsson on 2/16/2010 11:27 AM:
>>> ../gllib/libgnu.a(error.o): In function `print_errno_message':
>>> /home/Simon/gnulib/build/gllib/error.c:153: undefined reference to 
>>> `_libintl_gettext'
>>> collect2: ld returned 1 exit status
>>> make[3]: *** [test-userspec.exe] Error 1
>>>
>>> I'll commit the patch below unless anyone objects.
>>
>> Looks correct to me.  Go ahead.
>
> Done, thanks for review it.

Oh!  Sorry I didn't see that sooner.
The "userspec-tests" in the subject didn't register.

gnulib bootstrap and git submodules

[Eric Blake]

git 1.6.4 learned 'git submodule add --reference dir' as a means to make
initializing git submodules use (MUCH) less bandwidth and disk space by
borrowing references from an existing on-disk repository, rather than
cloning from scratch.  I would like to modify the bootstrap script to
honor $GNULIB_SRCDIR, if set, as the argument to the --reference
directory, to take advantage of this git feature.  Keep in mind that if
someone sets GNULIB_SRCDIR, it should be to a master repository that does
not get rewound, to avoid issues with the client repositories ever
depending on references that might go stale during garbage collection in
the reference repository (but with gnulib's linear development model, that
is probably not too much of a concern).  Any objections?

Additionally, the m4 bootstrap script (m4 does not use the gnulib
bootstrap script) is able to perform the same operation even with older
git-submodule that does not support the --reference action, by breaking
things down into multiple steps and using git-clone --reference instead.
Is that worth incorporating into my proposed patch for gnulib's bootstrap,
or should we just assume that git 1.6.4 or newer is widespread enough to
not be worth the hassle?

-- 
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net



signature.asc
Description: OpenPGP digital signature

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

[Ludovic Courtès]

Hi,

Simon Josefsson  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Simon Josefsson  writes:
>>
>>> l...@gnu.org (Ludovic Courtès) writes:
>>>
 What I meant to say is that it should return an error because resolving
 the ‘does-not-exist’ service fails.
>>>
>>> Does it only fail (well, falsely succeed) for unknown services?
>>
>> When asked for a host name that does not resolve, it returns an error,
>> as expected.
>
> For unknown services?  Interesting.  What about known services, does it
> resolve them correctly?

I don’t know, but I’d expect it to work since otherwise the function is
really useless.

> If the problem is that unknown services (for existing names) results in
> port 0, we could work around that by wrapping the system getaddrinfo in
> a check whether port is 0 and then return EAI_SERVICE.

Possibly, unless PORT = 0 can have a special meaning, but that doesn’t
appear to be the case.

[...]

>> If it is indeed a bug, should we try to work around it in Gnulib?
>> Any idea how this could be done?
>
> Given that this is a bug (which isn't clear to me yet), we could work
> around it.

 I agree in principle, of course, but I can’t think of a way to work
 around that since we’ll always have to rely on libc at one point or
 another.
>>>
>>> It should be possible to look up services in other ways (getservbyname),
>>> right?
>>
>> Yes, but what if getservbyname is similarly broken?  That wouldn’t be
>> surprising if these functions are factorized.
>
> We can replace broken getservbyname too.

Yes, but sooner or later, we’ll have to build on a libc function that
works.  :-)

>>> If you use the getaddrinfo replacement in gnulib on that system,
>>> doesn't it produce correct results?
>>
>> It’s not used by default.  How can I force it to be used?
>
> Try building using './configure gl_cv_func_getaddrinfo=no'.

OK, long story short: Guile has new ‘getaddrinfo’ bindings, with the
same parameters as the C version.  The tests are here:

  
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=test-suite/tests/net-db.test

When run with the Gnulib replacement on Darwin 9.2.2, we get:

--8<---cut here---start->8---
Running net-db.test
ERROR: net-db.test: getaddrinfo: 127.0.0.1, any service - arguments: 
((getaddrinfo-error 3))
ERROR: net-db.test: getaddrinfo: 127.0.0.1:80 - arguments: ((getaddrinfo-error 
3))
ERROR: net-db.test: getaddrinfo: port 80 - arguments: ((getaddrinfo-error 3))
ERROR: net-db.test: getaddrinfo: port 80 with family and socket type - 
arguments: ((getaddrinfo-error 3))
FAIL: net-db.test: getaddrinfo: no name
FAIL: net-db.test: getaddrinfo: wrong service name
--8<---cut here---end--->8---

Error code 3 is ‘EAI_BADFLAGS’.

When run without the Gnulib replacement, the only test that fails is
“wrong service name”.

IOW the Gnulib replacement seems to be bogus.

Sorry, I can’t really provide better info.

> But it is also not clear to me that the test-case above indicate a
> useful way of using getaddrinfo, what kind of application uses
> parameters like that, and what result did you expect?

 An error, because the service name doesn’t resolve.
>>>
>>> What if the system is configured (or programmed) to resolve all services
>>> names?  Isn't that a valid POSIX compliant getaddrinfo implementation?
>>> It's not particular useful one, I admit.
>>
>> But then a given program wouldn’t be able to do anything useful with it.
>> For instance, getaddrinfo ("host", "http") would be useless if the
>> resulting port were not 80, because clients elsewhere may still get 80,
>> because that’s what IANA has always said.
>
> Right.  I'm not sure how gnulib should behave here.
>
> First, there is nothing in POSIX (I think?) that says "http" must always
> resolve to port 80, and that "unknown-non-existing-service" must result
> in an error.  To the contrary, getaddrinfo/getservbyname typically reads
> /etc/services, which allows administrators to modify the "http" port to
> something else.  So "http" is likely not even intended to be guaranteed
> to translate into 80 by POSIX.

Right.

> But anything but 80 is useless for portable applications.  Should
> gnulib to replace a system getaddrinfo that doesn't translate "http"
> to 80?

No, I think this is getting too far.

My initial request was: make sure getaddrinfo(3) returns an error when
asked for non-existent service.  The only OS that fails at this test is
Darwin 9.2.2.

Thanks,
Ludo’.

Re: gnulib bootstrap and git submodules

[Paolo Bonzini]

On 02/17/2010 02:57 PM, Eric Blake wrote:

Any objections?


Where is the patch? ;-)

Paolo

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

[Paolo Bonzini]

int
main (int argc, char *argv[])
{
   int err;
   struct addrinfo *res, hints;

   memset (&hints, 0, sizeof (hints));
   err = getaddrinfo (NULL, "does-not-exist",&hints,&res);
   printf ("err = %i `%s'\n", err, gai_strerror (err));

   return err != 0 ? EXIT_SUCCESS : EXIT_FAILURE;
}
--8<---cut here---end--->8---

Here, I’d expect either ‘EAI_NONAME’ or ‘EAI_SERVICE’ (glibc 2.11
returns the latter on GNU/Linux).  On ‘i386-apple-darwin9.2.2’ it
succeeds:

   err = 0 `Unknown error'

My guess is that it’s a bug.  What do you think?

If it is indeed a bug, should we try to work around it in Gnulib?
Any idea how this could be done?


Out of curiosity, what does getservbyname("does-not-exist", NULL) return?

Paolo

Re: gnulib bootstrap and git submodules

[Jim Meyering]

Eric Blake wrote:
> git 1.6.4 learned 'git submodule add --reference dir' as a means to make
> initializing git submodules use (MUCH) less bandwidth and disk space by
> borrowing references from an existing on-disk repository, rather than
> cloning from scratch.  I would like to modify the bootstrap script to
> honor $GNULIB_SRCDIR, if set, as the argument to the --reference
> directory, to take advantage of this git feature.  Keep in mind that if
> someone sets GNULIB_SRCDIR, it should be to a master repository that does
> not get rewound, to avoid issues with the client repositories ever
> depending on references that might go stale during garbage collection in
> the reference repository (but with gnulib's linear development model, that
> is probably not too much of a concern).  Any objections?

Good idea.
I will use it, and end up saving at least 5 copies worth.

> Additionally, the m4 bootstrap script (m4 does not use the gnulib
> bootstrap script) is able to perform the same operation even with older
> git-submodule that does not support the --reference action, by breaking
> things down into multiple steps and using git-clone --reference instead.
> Is that worth incorporating into my proposed patch for gnulib's bootstrap,
> or should we just assume that git 1.6.4 or newer is widespread enough to
> not be worth the hassle?

I'd prefer to assume git 1.6.4 to keep things simpler, at least until
someone comes up with a compelling reason to add code to support older git.

Re: gnulib bootstrap and git submodules

[Eric Blake]

According to Paolo Bonzini on 2/17/2010 10:10 AM:
> On 02/17/2010 02:57 PM, Eric Blake wrote:
> > Any objections?
>
> Where is the patch?
>

Here's my first cut at it.  Beware that it is a slight semantic change
from Jim's commit 9efa515ce last November; but I actually prefer my
semantics.  With Jim's semantics and with GNULIB_SRCDIR set in my
environment, the mere act of running ./bootstrap was giving me dirty trees
because .gitmodules was modified; I ended up having to run 'env -u
GNULIB_SRCDIR ./bootstrap' in projects that were using variants of
gnulib's bootstrap.  Also, remember that you have to actually copy the
updated bootstrap into your project to benefit from the change (for
example, I noticed that coreutils' copy of bootstrap has several unrelated
differences compared to gnulib's copy).

But I won't push without more feedback, particularly if Jim has an
argument of why to keep his semantics, or if we need to introduce some
alternate means of supporting his intent of quickly testing a one-off grab
from the latest and greatest local copy of gnulib rather than the
configured commit and location stored in .gitmodules.


From: Eric Blake 
Date: Wed, 17 Feb 2010 11:42:16 -0700
Subject: [PATCH] bootstrap: use GNULIB_SRCDIR to reduce disk usage

This slightly changes the semantics of GNULIB_SRCDIR; previously,
it was a way to change the contents of .gitmodules to actually
point to a new location, which meant that running:
 GNULIB_SRCDIR=~/gnulib ./bootstrap
would result in a dirty tree.  The new semantics are nicer; the
submodule is cloned as normal, but the clone uses the original
$GNULIB_SRCDIR as an object reference to reduce download time
and disk space, all without modifying .gitmodules.  And you can
continue to use proj/.git/config to override proj/.gitmodules,
if you don't like pulling from the canonical upstream.

* build-aux/bootstrap (GNULIB_SRCDIR): If set, use as a reference,
rather than reconfiguring where the submodule points.

Signed-off-by: Eric Blake 
---
 ChangeLog   |6 ++
 build-aux/bootstrap |   10 +++---
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c240412..d5eec63 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-02-17  Eric Blake  
+
+   bootstrap: use GNULIB_SRCDIR to reduce disk usage
+   * build-aux/bootstrap (GNULIB_SRCDIR): If set, use as a reference,
+   rather than reconfiguring where the submodule points.
+
 2009-11-17  Eric Blake  

manywarnings: add more warnings
diff --git a/build-aux/bootstrap b/build-aux/bootstrap
index 0fb0ac5..1595d1b 100755
--- a/build-aux/bootstrap
+++ b/build-aux/bootstrap
@@ -43,7 +43,7 @@ Options:
   sources reside.  Use this if you already
   have gnulib sources on your machine, and
   do not want to waste your bandwidth downloading
-  them again.
+  them again.  Defaults to \$GNULIB_SRCDIR.
  --copy   Copy files instead of creating symbolic links.
  --force  Attempt to bootstrap even if the sources seem
   not to have been checked out.
@@ -421,15 +421,11 @@ case ${GNULIB_SRCDIR--} in
   GNULIB_SRCDIR=gnulib
   ;;
 *)
-  # Redirect the gnulib submodule to the directory on the command line
-  # if possible.
+  # Use GNULIB_SRCDIR as a reference.  Assumes git 1.6.4 or newer.
   if test -d "$GNULIB_SRCDIR"/.git && \
 git_modules_config submodule.gnulib.url >/dev/null; then
-git submodule init
-GNULIB_SRCDIR=`cd $GNULIB_SRCDIR && pwd`
-git_modules_config --replace-all submodule.gnulib.url $GNULIB_SRCDIR
 echo "$0: getting gnulib files..."
-git submodule update || exit $?
+git submodule update --init --reference "$GNULIB_SRCDIR" gnulib ||
exit $?
 GNULIB_SRCDIR=gnulib
   fi
   ;;
-- 
1.6.6.1



signature.asc
Description: OpenPGP digital signature

Re: gnulib bootstrap and git submodules

[Paolo Bonzini]

On 02/17/2010 09:20 PM, Eric Blake wrote:

-git_modules_config --replace-all submodule.gnulib.url $GNULIB_SRCDIR


I think this was definitely wrong.  .git/config overrides .gitmodules 
exactly so that you can place submodule.*.url entries there that point 
to local repositories.


--reference is another way to achieve a similar effect.

Paolo

Re: NetBSD 5.0’s lacks AI_* macros

[Bruno Haible]

Simon Josefsson wrote:
> fixed as below.  ... So this is a bug in NetBSD netdb.h

I'm adding a mention of it to the doc:


2010-02-17  Bruno Haible  

* doc/posix-headers/netdb.texi: Mention NetBSD 5.0 problem.
Reported by Ludovic Courtès .

*** doc/posix-headers/netdb.texi.orig   Thu Feb 18 00:28:50 2010
--- doc/posix-headers/netdb.texiThu Feb 18 00:27:41 2010
***
*** 14,19 
--- 14,24 
  @item
  This header file is incomplete on some platforms:
  Cygwin 1.5.x, Haiku.
+ 
+ @item
+ This header file does not define @code{AI_ALL}, @code{AI_V4MAPPED},
+ @code{AI_ADDRCONFIG} on some platforms:
+ NetBSD 5.0.
  @end itemize
  
  Portability problems not fixed by Gnulib:

error: redefinition of 'struct option'

[Bruce Korb]

make[3]: Entering directory `/old-home/gnu/proj/sharutils-bld/lib'
make[4]: Entering directory `/old-home/gnu/proj/sharutils-bld/lib'
gcc -DHAVE_CONFIG_H -I. -I.. -g -Wall -MT close-hook.o -MD -MP -MF 
.deps/close-hook.Tpo -c -o close-hook.o close-hook.c
In file included from ./xstrtol.h:22,
 from ../config.h:1469,
 from close-hook.c:18:
./getopt.h:195: error: redefinition of 'struct option'



The preprocessed source contains this text:

> # 106 "/usr/include/getopt.h" 3 4
> struct option
> {
>   const char *name;
> 
> 
>   int has_arg;
>   int *flag;
>   int val;
> };
> []
> # 194 "./getopt.h" 3
> struct option
> {
>   const char *name;
> 
> 
>   int has_arg;
>   int *flag;
>   int val;
> };

=== Oops.

The *un*preprocessed gnulib-installed getopt.h has this:

> #ifndef _GL_GETOPT_H
> 
> #if __GNUC__ >= 3
> #pragma GCC system_header
> #endif
> 
> /* The include_next requires a split double-inclusion guard.  We must
>also inform the replacement unistd.h to not recursively use
>; our definitions will be present soon enough.  */
> #if 1
> # define _GL_SYSTEM_GETOPT
> # include_next 
> # undef _GL_SYSTEM_GETOPT
> #endif
> 
> #ifndef _GL_GETOPT_H

That looks wrong to me.  I guess the include_next will
define _GL_GETOPT_H sometimes if _GL_SYSTEM_GETOPT is defined.
OK.  Whatever.  The problem is that I'm getting "struct option"
defined twice.  The second "#ifndef _GL_GETOPT_H" should be trained
to cope with a valid getopt.h that doesn't understand _GL_SYSTEM_GETOPT.



Suggestions, please?  Thank you.

Re: error: redefinition of 'struct option'

[Eric Blake]

According to Bruce Korb on 2/17/2010 7:03 PM:
> make[3]: Entering directory `/old-home/gnu/proj/sharutils-bld/lib'
> make[4]: Entering directory `/old-home/gnu/proj/sharutils-bld/lib'
> gcc -DHAVE_CONFIG_H -I. -I.. -g -Wall -MT close-hook.o -MD -MP -MF 
> .deps/close-hook.Tpo -c -o close-hook.o close-hook.c
> In file included from ./xstrtol.h:22,
>  from ../config.h:1469,
>  from close-hook.c:18:
> ./getopt.h:195: error: redefinition of 'struct option'

What platform is this on?  Is this a fresh bootstrap, with a modern git
checkout, or are you doing some incremental builds where you might have an
out-of-date getopt.h that needs to be regenerated?  Are you sure that
 is the first header included from withing close-hook.c?

> The *un*preprocessed gnulib-installed getopt.h has this:
> 
>> #ifndef _GL_GETOPT_H
>>
>> #if __GNUC__ >= 3
>> #pragma GCC system_header
>> #endif
>>
>> /* The include_next requires a split double-inclusion guard.  We must
>>also inform the replacement unistd.h to not recursively use
>>; our definitions will be present soon enough.  */
>> #if 1
>> # define _GL_SYSTEM_GETOPT
>> # include_next 
>> # undef _GL_SYSTEM_GETOPT
>> #endif
>>
>> #ifndef _GL_GETOPT_H
> 
> That looks wrong to me.  I guess the include_next will
> define _GL_GETOPT_H sometimes if _GL_SYSTEM_GETOPT is defined.

No, it is correct.  It is defining _GL_GETOPT_H so that the
gnulib-installed  won't try to do stupid things if the system
 tries to include .

> OK.  Whatever.  The problem is that I'm getting "struct option"
> defined twice.  The second "#ifndef _GL_GETOPT_H" should be trained
> to cope with a valid getopt.h that doesn't understand _GL_SYSTEM_GETOPT.

The _only_ getopt.h that understands _GL_SYSTEM_GETOPT is gnulib's
getopt.h.  No one else should be defining or undefining that symbol, and
only gnulib's unistd.h should be checking if it is defined.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net



signature.asc
Description: OpenPGP digital signature

Re: error: redefinition of 'struct option'

[Bruce Korb]

Hi Eric,

Thanks for the feedback.
Unfortunately, it didn't help:

Eric Blake wrote:
> According to Bruce Korb on 2/17/2010 7:03 PM:
>> make[3]: Entering directory `/old-home/gnu/proj/sharutils-bld/lib'
>> make[4]: Entering directory `/old-home/gnu/proj/sharutils-bld/lib'
>> gcc -DHAVE_CONFIG_H -I. -I.. -g -Wall -MT close-hook.o -MD -MP -MF 
>> .deps/close-hook.Tpo -c -o close-hook.o close-hook.c
>> In file included from ./xstrtol.h:22,
>>  from ../config.h:1469,
>>  from close-hook.c:18:
>> ./getopt.h:195: error: redefinition of 'struct option'
> 
> What platform is this on?

$ ./config.guess ; cat /etc/SuSE-release
x86_64-unknown-linux-gnu
openSUSE 11.1 (x86_64)
VERSION = 11.1

>  Is this a fresh bootstrap, with a modern git

Current as of 2/17/2010 7:03 PM
$ for f in autoconf automake libtool ; do $f --version | sed 1q ; done
autoconf (GNU Autoconf) 2.65
automake (GNU automake) 1.11.1
ltmain.sh (GNU libtool) 2.2.6

> checkout, or are you doing some incremental builds where you might have an
> out-of-date getopt.h that needs to be regenerated?

My build procedure is to blow away the build tree, copy in the
repository source files and do the build.  It doesn't get any cleaner.

>  Are you sure that
>  is the first header included from withing close-hook.c?

Not my responsibility (it's gnulib source), but:

> #include 
> 
> /* Specification.  */
> #include "close-hook.h"
> 
> #include 
> #include 
> 
> #undef close

Looks good to me.

>> The *un*preprocessed gnulib-installed getopt.h has this:
>>
>>> #ifndef _GL_GETOPT_H
>>>
>>> #if __GNUC__ >= 3
>>> #pragma GCC system_header
>>> #endif
>>>
>>> /* The include_next requires a split double-inclusion guard.  We must
>>>also inform the replacement unistd.h to not recursively use
>>>; our definitions will be present soon enough.  */
>>> #if 1
>>> # define _GL_SYSTEM_GETOPT
>>> # include_next 
>>> # undef _GL_SYSTEM_GETOPT
>>> #endif
>>>
>>> #ifndef _GL_GETOPT_H
>> That looks wrong to me.  I guess the include_next will
>> define _GL_GETOPT_H sometimes if _GL_SYSTEM_GETOPT is defined.
> 
> No, it is correct.  It is defining _GL_GETOPT_H so that the
> gnulib-installed  won't try to do stupid things if the system
>  tries to include .

Then what purpose is the second "#ifndef _GL_GETOPT_H" since it is
nested within the identical guard several lines above?
It looks confusing to me, even if it may not be "wrong".

>> OK.  Whatever.  The problem is that I'm getting "struct option"
>> defined twice.  The second "#ifndef _GL_GETOPT_H" should be trained
>> to cope with a valid getopt.h that doesn't understand _GL_SYSTEM_GETOPT.
> 
> The _only_ getopt.h that understands _GL_SYSTEM_GETOPT is gnulib's
> getopt.h.  No one else should be defining or undefining that symbol, and
> only gnulib's unistd.h should be checking if it is defined.

Then what's with the #define and #undef all about?
#include_next is going to get (does get, per CPP output)
the /usr/include/getopt.h file.  The bottom line is that
struct option gets defined twice.  Once in gnulib's getopt.h and
again in the /usr/include file.

Thank you for your ideas.  Regards, Bruce

Re: NetBSD 5.0’s lacks AI_* macros

[Simon Josefsson]

Bruno Haible  writes:

> Simon Josefsson wrote:
>> fixed as below.  ... So this is a bug in NetBSD netdb.h
>
> I'm adding a mention of it to the doc:

Thanks.

/Simon

Re: Cygwin build report on Windows XP

[Simon Josefsson]

Bruno Haible  writes:

>> Starting test_cond .../bin/sh: line 5:  3124 Aborted (core 
>> dumped)
>> FAIL: test-cond.exe
>> 
>> Starting test_lock .../bin/sh: line 5:  1336 Aborted (core 
>> dumped)
>> FAIL: test-lock.exe
>> 
>> Starting test_tls .../bin/sh: line 5:  3444 Aborted (core 
>> dumped)
>> FAIL: test-tls.exe
>
> The pthread implementation is apparently broken on Cygwin, see
> . I have added some
> code to m4/threadlib.m4 that disables threads on Cygwin 1.5.x by default.
> So, for me, the results are:
>
>   SKIP: test-cond.exe
>
>   Skipping test: multithreading not enabled
>   SKIP: test-lock.exe
>
>   Skipping test: multithreading not enabled
>   SKIP: test-tls.exe
>
> [Oops, 'test-cond' should display the reason why the test is being skipped.]
>
> What's the result of "uname -r" on your machine?

I still get failures here, for Cygwin 1.7.x:

Starting test_cond .../bin/sh: line 5:  3504 Aborted (core 
dumped)
FAIL: test-cond.exe
...
Starting test_lock .../bin/sh: line 5:  3500 Aborted (core 
dumped)
FAIL: test-lock.exe
...
Starting test_tls .../bin/sh: line 5:  2560 Aborted (core 
dumped)
FAIL: test-tls.exe

See http://autobuild.josefsson.org/gnulib/log-201002171652277193000.txt

Should m4/threadlib.m4 disable threads on cygwin 1.7.x too?  There is a
1.[0-5].* regexp in there now.

/Simon

Re: Cygwin build report on Windows XP

[Simon Josefsson]

Simon Josefsson  writes:

> The build times are interesting:
>
> gnulib-tool: 324 minutes
> ./configure: 36 minutes
> make check: 34 minutes

Another build, on the same physical hardware, is available from:

http://autobuild.josefsson.org/gnulib/log-201002171652277193000.txt

The build times are now:

gnulib-tool: 418 minutes
./configure: 43 minutes
make check: 38 minutes

Haven't we applied some of Ralf's speedup patches?  Any ideas why it is
now slower?

/Simon