Re: Project management and code quality tools

[Ludovic Courtès]

Hi,

Simon Josefsson <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] writes:

>> I think it is a really good idea. If the scripts are distributed in
>> gnulib more GNU packages will be using them and improving them.
>
> Thanks for feedback, I have pushed the module into gnulib.

That's good news!  I'm also a big fan of GNU PDF's tools, so thank you!

Ludo'.

Re: Generating code coverage reports

[Ludovic Courtès]

Hi,

Simon Josefsson <[EMAIL PROTECTED]> writes:

> build-coverage:
>   make CFLAGS=$(COVERAGE_OPTS) CXXFLAGS=$(COVERAGE_OPTS) VALGRIND=
>   make CFLAGS=$(COVERAGE_OPTS) CXXFLAGS=$(COVERAGE_OPTS) VALGRIND= check
>   mkdir -p doc/coverage
>   lcov --directory . --output-file doc/coverage/$(PACKAGE).info --capture

I'm not sure this is correct, because the `.gcda' files that are used as
input in the end do not summarize the code covered by every single test.
Concretely, this means that lcov's output slightly underestimates code
coverage.

Let me explain this.  Suppose you have tests T1 and T2:

  * T1 uses code from foo.c and t1.c;
  * T2 uses code from foo.c and t2.c.

Running "make check" runs T1, then T2:

  * T1 is run, producing foo.gcda and t1.gcda;
  * T2 is run, *overriding* foo.gcda and producing t2.gcda.

In the end, `lcov' is fed with foo.gcda from the T2 run, whereas what we
really want to have is the code covered in foo.c by T1 *and* T2.

Thus, after each test run, all GCDA files produced should be fed to
`lcov' (thereby producing a `.info' file) and removed; once all tests
run, all `.info' files should be aggregated (using "lcov -a"), and
finally fed to `genhtml'.

Does that make sense?

Thanks,
Ludo'.

Re: Generating code coverage reports

[Ludovic Courtès]

Hi Ralf,

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> Hello Ludovic, Simon,
>
> * Ludovic Courtès wrote on Tue, Oct 28, 2008 at 05:48:12PM CET:
>> 
>> Let me explain this.  Suppose you have tests T1 and T2:
>> 
>>   * T1 uses code from foo.c and t1.c;
>>   * T2 uses code from foo.c and t2.c.
>> 
>> Running "make check" runs T1, then T2:
>> 
>>   * T1 is run, producing foo.gcda and t1.gcda;
>>   * T2 is run, *overriding* foo.gcda and producing t2.gcda.
>> 
>> In the end, `lcov' is fed with foo.gcda from the T2 run, whereas what we
>> really want to have is the code covered in foo.c by T1 *and* T2.
>
> That's not what my GCC documentation says (info gcc 'Invoking Gcov',
> near the end):
>
>The execution counts are cumulative.  If the example program were
>   executed again without removing the `.gcda' file, the count for the
>   number of times each line in the source was executed would be added to
>   the results of the previous run(s). [...]

Oh, you're right.  The GCC 4.2 manual contains the same paragaph:
http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Invoking-Gcov.html#Invoking-Gcov .

Sorry for the confusion.

> FWIW, IIRC then the directory handling of the files was only fixed to be
> sane rather recently in the GCC tree (I guess 4.4 only).

By "directory handling", you mean the location where GCDA files are
produced relative to the location of the corresponding `.o' files?

Thanks,
Ludo'.

Re: Generating code coverage reports

[Ludovic Courtès]

Hi Simon,

Simon Josefsson <[EMAIL PROTECTED]> writes:

> +COVERAGE_CCOPTS ?= "-g -fprofile-arcs -ftest-coverage"

Looks to me that `--coverage' is more appropriate as it adds all `-f'
options that are needed, so it's potentially more "future-proof".

Also, LDFLAGS must be modified to do either `-lgcov' or, again,
`--coverage'.

Thanks,
Ludo'.

Re: Generating code coverage reports

[Ludovic Courtès]

Simon Josefsson <[EMAIL PROTECTED]> writes:

> Yes, but it seems that --coverage is passed to the command line to link
> applications with CFLAGS:
>
> [EMAIL PROTECTED]:~/src/libidn/src master$ rm idn
> [EMAIL PROTECTED]:~/src/libidn/src master$ make CFLAGS="-g --coverage"
> make  all-am
> make[1]: Entering directory `/home/jas/src/libidn/src'
> /bin/bash ../libtool --tag=CC   --mode=link gcc -std=gnu99 -Wall -Werror -g 
> --coverage   -o idn idn.o idn_cmd.o ../lib/libidn.la ../gl/libgnu.la  
> libtool: link: gcc -std=gnu99 -Wall -Werror -g --coverage -o .libs/idn idn.o 
> idn_cmd.o  ../lib/.libs/libidn.so ../gl/.libs/libgnu.a

Ah, right: CFLAGS are also used at link time, so everything's alright.

Thanks,
Ludo'.

Re: Generating code coverage reports

[Ludovic Courtès]

Hi Simon,

Simon Josefsson <[EMAIL PROTECTED]> writes:

> Hi Ludovic.  Thanks, I pushed this patch.  Adding anything to LDFLAGS
> doesn't seem to be required though?

According to the doc (info "(gcc)Debugging Options") it is required.
See also this example (with GCC 4.2.4):

  $ cat > t.c < Btw, it is better/worse to compile with -O2?  It may be better for
> profiling optimizations, but the use-case here is to generate code
> coverage reports for the self tests.  So I would assume -O2 is harmful
> here.  Whether -g is useful or not is another question.

I don't think `-O' matters.  I don't think `-g' is required to get
useful source location information.

Thanks,
Ludo'.

Re: [gnu-prog-discuss] url's in --help output

[Ludovic Courtès]

Hello,

Simon Josefsson  writes:

> I suggest a new gnulib module emit-bug-reporting-address.  I have the
> following code in GNU Libidn, which is strongly influenced by GNU
> CoreUtils.  Removing the 'static' keyword and putting it in a gnulib
> module would make it easy to re-use the code, and possibly also the
> translation messages.  I would use it in several of my projects.
> Thoughts?  I'll propose a patch shortly.

Is there any reason this cannot be made part of `version-etc'?

Thanks,
Ludo'.

Re: [gnu-prog-discuss] url's in --help output

[Ludovic Courtès]

Simon Josefsson  writes:

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

>> Is there any reason this cannot be made part of `version-etc'?
>
> No reason.  It seems like a better place actually.  Jim, how about this
> patch?

And while we're at it, can't `version_etc ()' print the bug-reporting
information itself?  OTOH, Karl's message suggests that it's the job of
`--help', not `--version', so it may not be a good idea.

Thanks,
Ludo'.

License inconsistency for `verify'

[Ludovic Courtès]

Hello,

The `verify' module appears as LGPLv2+-licensed but  says
GPLv3+.  Commit b6f8b81b changed the license from LGPL to LGPLv2+, so I
suppose it's the header that's incorrect.  Am I right?

Thanks,
Ludo'.

Re: License inconsistency for `verify'

[Ludovic Courtès]

Hello,

Bruno Haible  writes:

> Ludovic Courtès wrote:
>> The `verify' module appears as LGPLv2+-licensed but  says
>> GPLv3+.
>
> This is normal. See the README, section "License", or the manual [1].

Thanks for the clarification.

Is it just out of convenience that license headers are always kept
GPLv3+?

Thanks,
Ludo'.

Broken isnan(3) and/or DQNAN on Tru64

[Ludovic Courtès]

Hello,

On `alphaev56-dec-osf5.1b', NaN handling seems to be deeply broken.
Consider this piece of code:

--8<---cut here---start->8---
#include 

extern unsigned int DQNAN[2];

int
main (int argc, char *argv[])
{
  return isnan (* (double *) DQNAN);
}
--8<---cut here---end--->8---

When compiled with GCC 4.0.2, it bails out with SIGFPE.

Guile's 1.8 series does not use Gnulib (the next release series will use
Gnulib), so it's been relying on these facilities, which are also used
in Octave.  I'm wondering whether it worked with older Tru64 versions.

I know Gnulib's `isnan' module re-implements isnan(3) following the IEEE
specs, but in your experience is there any way to get a working isnan(3)
on Tru64?  Or perhaps it's DQNAN that's broken?

Thanks in advance,
Ludo'.

Re: Broken isnan(3) and/or DQNAN on Tru64

[Ludovic Courtès]

Hi Bruno,

Bruno Haible  writes:

> What's the result when you compile it with cc?
>   $ cc foo.c -lm
>   $ ./a.out
>   $ echo $?

1

That's with "Compaq C V6.5-303 (dtk) on Compaq Tru64 UNIX V5.1B
(Rev. 2650)".

Should we conclude that this is a GCC bug?  I'll try with different
versions.

> What's the result for a program that uses a quiet NaN, computed
> differently?
>
>   #include 
>   double zero = 0.0;
>   int main()
>   {
> return isnan (zero / zero);
>   };

SIGFPE with both `cc' and GCC 4.0.2.

> And finally, what's the hexdump of that DQNAN constant?
>
>   #include 
>   #include 
>   int main()
>   {
> printf("%04X%04X\n", DQNAN[1], DQNAN[0]);
> return 0;
>   }

FFF8

Quite different from what we have on GNU in ...

Thanks,
Ludo'.

Re: Broken isnan(3) and/or DQNAN on Tru64

[Ludovic Courtès]

Hello,

Bruno Haible  writes:

> I meant %08X instead of %04X. DQNAN therefore likely is
>   FFF8
> which decomposes into
>   sign = 1 (irrelevant for NaNs),
>   exponent = 0x7FF (highest possible value)
>   mantissa = 0x8
> and this is precisely the common encoding of a quiet NaN
> (see ).

Right.

>> > What's the result when you compile it with cc?
>> >   $ cc foo.c -lm
>> >   $ ./a.out
>> >   $ echo $?
>> 
>> 1
>> 
>> That's with "Compaq C V6.5-303 (dtk) on Compaq Tru64 UNIX V5.1B
>> (Rev. 2650)".
>> 
>> Should we conclude that this is a GCC bug?
>
> Possibly. And what result do you get with "gcc -mieee" ?

It works (returns 1).

The GCC manual (info "(gcc) DEC Alpha Options") reads this:

`-mieee'

 [...]
 This option generates code fully IEEE compliant code [...]

 The resulting code is less efficient but is able to correctly
 support denormalized numbers and exceptional IEEE values such as
 not-a-number and plus/minus infinity.

So people compiling with GCC on this platform should pass `-mieee'
(`configure' could add it automatically.)

Thanks for your help!

Ludo'.

Re: Broken isnan(3) and/or DQNAN on Tru64

[Ludovic Courtès]

Hi,

Bruno Haible  writes:

>> So people compiling with GCC on this platform should pass `-mieee'
>> (`configure' could add it automatically.)
>
> The gnulib module 'fpieee' adds it automatically.

This module appears to be overzealous: `gl_FP_IEEE' just checks for the
host CPU, but on alpha*-linux-gnu, `-mieee' is apparently not needed:

--8<---cut here---start->8---
#include 

int
main (int argc, char *argv[])
{
  return isnan (NAN);
}
--8<---cut here---end--->8---

Compiled with GCC 4.2.4 on Debian GNU/Linux on Alpha, it returns 1.

Or maybe that's a Debian patch that enables `-mieee' by default?

Thanks,
Ludo'.

Re: Broken isnan(3) and/or DQNAN on Tru64

[Ludovic Courtès]

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

> Or maybe that's a Debian patch that enables `-mieee' by default?

Actually yes, there's `debian/patches/alpha-ieee.dpatch', which is why I
didn't observe SIGFPEs on Debian GNU/Linux.

Ludo'.

have-lib: ‘additional_libdir’ set to ‘PREFIX/lib64’

[Ludovic Courtès]

Hello,

When passed ‘--with-PACKAGE-prefix=/p’, ‘AC_LIB_LINKFLAGS_BODY’
deduces ‘additional_libdir=/p/lib64’ on x86_64.

This doesn’t work on NixOS which doesn’t (quite) support multilib, and
where libs are to be found under ‘/p/lib’.  Unfortunately, this leads
‘AC_LIB_LINKFLAGS_BODY’ to ignore the ‘/p’ prefix altogether, both for
includes and libs (it ends up in the “Didn't find the library” case).

A simple fix would be to add a ‘--with-PACKAGE-lib’ (and optionally
‘--with-PACKAGE-include’) option.  A better fix may be to have
“additional_libdir="/p/lib64 /p/lib"” or similar.

What do you think?

Thanks,
Ludo’.

Re: have-lib: ‘additional_libdir’ set to ‘PREFIX/lib64’

[Ludovic Courtès]

Hi Bruno,

Bruno Haible  writes:

> You can just as well set CPPFLAGS and LDFLAGS manually, then. Recall that
> the --with-PACKAGE-prefix option is merely a shortcut for what can
> be specified by setting CPPFLAGS and LDFLAGS appropriately.

Right.

> This will placate the real problem. The real problem is that on a system
> where gcc knows to find 64-bit libraries under /usr/lib64, NixOS will -
> according to what you say - use a different naming convention than what
> the rest of the system does. User confusion is guaranteed.

Well, there’s no /usr, and in fact no /lib nor /lib64 under NixOS.  Each
package has a different prefix, so we end up with
/nix/store/XYZ-PACKAGE/lib.

(Actually, bi-arch support wouldn’t make much sense under Nix’s view of
the world.)

Thanks,
Ludo’.

getopt compilation failure on Darwin (gzip 1.3.13)

[Ludovic Courtès]

Hello,

(Cc’ing ‘bug-gnulib’ as this looks like a Gnulib issue.)

GNU zip 1.3.13 fails to build on Darwin:

--8<---cut here---start->8---
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -g -O2 -c getopt.c
In file included from ./getopt.h:28,
 from getopt.h:28,
 from getopt.c:26:
/usr/include/getopt.h:54: error: redefinition of 'struct rpl_option'
/usr/include/getopt.h:70: error: conflicting types for 'rpl_getopt_long'
./getopt.h:227: error: previous declaration of 'rpl_getopt_long' was here
/usr/include/getopt.h:72: error: conflicting types for 'rpl_getopt_long_only'
./getopt.h:231: error: previous declaration of 'rpl_getopt_long_only' was here
make[3]: *** [getopt.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
--8<---cut here---end--->8---

Ideas?

Thanks,
Ludo’.

Re: getopt compilation failure on Darwin (gzip 1.3.13)

[Ludovic Courtès]

Hi Eric,

Eric Blake  writes:

> The circle was:
> ./getopt.h did include_next 
>   did include , but found ./unistd.h
>   ./unistd.h did include_next 
>completed
>   ./unistd.h did include , and found ./getopt.h
>./getopt.h declared things
>   ./unistd.h completed
>   redeclared things
>
> The solution is to teach ./unistd.h to skip  if the system
>  was the guy including unistd.  That way, both the system
>  and  can run to completion prior to ./getopt.h
> declaring overrides.
>
> I will be pushing this, if further testing proves that it doesn't break
> Linux or FreeBSD.

Thanks for the quick reply and patch!

It now builds properly on GNU/Linux, Darwin, and Cygwin in NixOS/Nixpkgs
(see latest builds at http://hydra.nixos.org/job/nixpkgs/stdenv/gzip/all).

Ludo’.

Explicit interpreter paths considered harmful

[Ludovic Courtès]

Hello,

A number of maintainer scripts explicitly use ‘#!/usr/bin/perl’ or
similar, but not all systems have Perl at this location (distros such as
NixOS and GoboLinux don’t have it there, and users in general are free
to install it elsewhere anyway.)

Of course it’d be unreasonable to have ‘AC_PATH_PROG([PERL], [perl])’
just so that, say, ‘gitlog-to-changelog’ uses the right interpreter.

Thus, I was thinking of something along the following lines:

--- a/build-aux/gitlog-to-changelog
+++ b/build-aux/gitlog-to-changelog
@@ -1,4 +1,7 @@
-#!/usr/bin/perl
+#!/bin/sh
+# Accommodate systems where /usr/bin/perl is not the right path.
+exec perl -x "$0" "$@"
+#!perl

The only assumption it makes is about /bin/sh, but that one seems to be
hard (impossible?) to avoid anyway.

What do you think?

Thanks,
Ludo’.

Re: Explicit interpreter paths considered harmful

[Ludovic Courtès]

Hi,

Paolo Bonzini  writes:

>> --- a/build-aux/gitlog-to-changelog
>> +++ b/build-aux/gitlog-to-changelog
>> @@ -1,4 +1,7 @@
>> -#!/usr/bin/perl
>> +#!/bin/sh
>> +# Accommodate systems where /usr/bin/perl is not the right path.
>> +exec perl -x "$0" "$@"
>> +#!perl
>>
>> The only assumption it makes is about /bin/sh, but that one seems to be
>> hard (impossible?) to avoid anyway.
>
> Yeah.  But why not the standard
>
> #! /bin/sh
> eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
> if 0;
>
> suggested in perlrun(1)?

You mean without ‘/usr/bin/’, right?  If so, then yes.

Thanks,
Ludo’.

Re: Explicit interpreter paths considered harmful

[Ludovic Courtès]

Hello,

Jim Meyering  writes:

> However, is this really necessary?
> You're not running gitlog-to-changelog manually, are you?
> If it's scripted, you can easily invoke it via "perl gitlog-to-changelog ..."

True, but then among the scripts under ‘build-aux’, some are invoked
directly by ‘maint.mk’, some like ‘announce-gen’ are typically invoked
manually, etc.  And they have the executable bit set anyway, so it feels
more natural to run them directly.

What do you think?

Thanks,
Ludo’.

Re: Explicit interpreter paths considered harmful

[Ludovic Courtès]

Hi Karl,

k...@freefriends.org (Karl Berry) writes:

> -#!/usr/bin/perl
> +#!/bin/sh
>
> Just to mention that an alternative would be #!/usr/bin/env perl.

It won’t work on NixOS, which doesn’t have /usr/bin.  (On NixOS, the
only “standard” path that can be relied on is /bin/sh.)

Thanks,
Ludo’.

Re: Explicit interpreter paths considered harmful

[Ludovic Courtès]

Paolo Bonzini  writes:

> Yeah.  But why not the standard
>
> #! /bin/sh
> eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
> if 0;
>
> suggested in perlrun(1)?

Actually that doesn’t work:

--8<---cut here---start->8---
$ ./build-aux/gitlog-to-changelog  
/bin/sh: -S: invalid option
--8<---cut here---end--->8---

because perl eventually execs /bin/sh:

--8<---cut here---start->8---
4473  execve("./build-aux/gitlog-to-changelog", 
["./build-aux/gitlog-to-changelog"], [/* 60 vars */]) = 0
4473  execve("/var/run/current-system/sw/bin/perl", ["perl", "-S", 
"./build-aux/gitlog-to-changelog"], [/* 59 vars */]) = 0
4473  execve("/bin/sh", ["/bin/sh", "-S", "./build-aux/gitlog-to-changelog"], 
[/* 59 vars */]) = 0
--8<---cut here---end--->8---

Actually perlrun(1) reads this:

--8<---cut here---start->8---
   #!/bin/sh -- # -*- perl -*- -p
   eval 'exec perl -wS $0 ${1+"$@"}'
   if $running_under_some_shell;
--8<---cut here---end--->8---

... which can’t possibly work.

So I guess I’ll stick to what I suggested.

Thanks,
Ludo’.

Re: Explicit interpreter paths considered harmful

[Ludovic Courtès]

Here's a patch.

Likewise, ‘pmccabe2html’ assumes /usr/bin/awk, but I’m not sure what to
do here:

  - ‘gl_PMCCABE2HTML’ does ‘AC_PROG_AWK’, so we could substitute @AWK@
in there.

  - OTOH, ‘pmccabe2html’ is typically a maintainer script, so I’d rather
remove ‘AC_PROG_AWK’ and do something similar to the patch below.

Thoughts?

Thanks,
Ludo’.

>From a75bd801044aeaa3df5406185ce5a298c75b1d6b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Thu, 29 Oct 2009 22:53:06 +0100
Subject: [PATCH] Don't assume the availability of /usr/bin/perl for build-aux scripts.

* build-aux/announce-gen, build-aux/gitlog-to-changelog,
  build-aux/update-copyright, build-aux/useless-if-before-free: Don't
  assume the availability of /usr/bin/perl.
---
 build-aux/announce-gen   |6 --
 build-aux/gitlog-to-changelog|6 --
 build-aux/update-copyright   |6 --
 build-aux/useless-if-before-free |4 +++-
 4 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/build-aux/announce-gen b/build-aux/announce-gen
index 972b881..024cb35 100755
--- a/build-aux/announce-gen
+++ b/build-aux/announce-gen
@@ -1,7 +1,9 @@
-#!/usr/bin/perl -w
+#!/bin/sh
+exec perl -wx "$0" "$@"
+#!perl
 # Generate a release announcement message.
 
-my $VERSION = '2009-09-11 09:50'; # UTC
+my $VERSION = '2009-10-29 21:47'; # UTC
 # The definition above must lie within the first 8 lines in order
 # for the Emacs time-stamp write hook (at end) to update it.
 # If you change this file with Emacs, please let the write hook
diff --git a/build-aux/gitlog-to-changelog b/build-aux/gitlog-to-changelog
index a0f8a08..4c3f428 100755
--- a/build-aux/gitlog-to-changelog
+++ b/build-aux/gitlog-to-changelog
@@ -1,7 +1,9 @@
-#!/usr/bin/perl
+#!/bin/sh
+exec perl -x "$0" "$@"
+#!perl
 # Convert git log output to ChangeLog format.
 
-my $VERSION = '2009-08-12 16:49'; # UTC
+my $VERSION = '2009-10-29 21:47'; # UTC
 # The definition above must lie within the first 8 lines in order
 # for the Emacs time-stamp write hook (at end) to update it.
 # If you change this file with Emacs, please let the write hook
diff --git a/build-aux/update-copyright b/build-aux/update-copyright
index 2480142..bb61808 100755
--- a/build-aux/update-copyright
+++ b/build-aux/update-copyright
@@ -1,7 +1,9 @@
-#!/usr/bin/perl -0777 -pi
+#!/bin/sh
+exec perl -x -0777 -pi "$0" "$@"
+#!perl
 # Update an FSF copyright year list to include the current year.
 
-my $VERSION = '2009-09-09.22:00'; # UTC
+my $VERSION = '2009-10-29.21:48'; # UTC
 
 # Copyright (C) 2009 Free Software Foundation, Inc.
 #
diff --git a/build-aux/useless-if-before-free b/build-aux/useless-if-before-free
index abcdef2..d707aee 100755
--- a/build-aux/useless-if-before-free
+++ b/build-aux/useless-if-before-free
@@ -1,4 +1,6 @@
-#!/usr/bin/perl -T
+#!/bin/sh
+exec perl -T -x "$0" "$@"
+#!perl
 # Detect instances of "if (p) free (p);".
 # Likewise for "if (p != NULL) free (p);".  And with braces.
 # Also detect "if (NULL != p) free (p);".
-- 
1.6.4.2

Reliance on

[Ludovic Courtès]

Hi,

I just noticed that Gnulib modules rely on the availability of a
`#include'able  file.

I'm using Gnulib in a project that does:

  AC_CONFIG_HEADER([some-special-name.h])

There, Gnulib modules fail to compile because  is not
available.  I'd happily work around this by doing something like:

  AC_CONFIG_HEADERS([some-special-name.h lib/config.h])

but then `autoheader' does not generate `lib/config.h.in', which is a
pain.

Any hint?

Thanks,
Ludovic.

Re: Reliance on

[Ludovic Courtès]

Hi,

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> Another possibility is to generate lib/config.h.in from
> some-special-name.h.in, say, by some sed script or an autoheader
> invocation with arguments and output redirection.

Good point.  I ended up using `AC_CONFIG_LINKS' to have a `config.h'
linked to `some-special-name.h'.

Eric Blake <[EMAIL PROTECTED]> writes:

> I think it will be easier for you to provide a stub lib/config.h than to
> try and restore all the sed invocations into gnulib-tool to convert to
> your custom name at checkout, not to mention that gnulib-tool is already
> slow enough as it is.

Possibly.  Still, that is one of the few things that doesn't work
automagically with Gnulib, so it's quite surprising at first.  ;-)

Alternatively, maybe `gnulib-tool --import' should say something like
"Make sure `lib/config.h' is available, e.g., by adding
`AC_CONFIG_LINKS(bla bla)' to your `configure.ac' file."

Thanks,
Ludovic.

Re: second call: please nail down the license terms of some more modules

[Ludovic Courtès]

Hi,

Bruno Haible <[EMAIL PROTECTED]> writes:

> Yoann Vandoorselaere wrote:
>> don't you think this could be a show stopper to early GnuLib adopters?
>
> No, I don't think so. Projects which have been using already cannot have
> missed the long thread here; projects which will adopt it in the future
> will see that there is no problem with the first few modules they need,
> and later on, they will ask.

Well, precisely, I've been considering the idea of using Gnulib in Guile
for some time and am willing to take action soon.  The issue is that
Guile is still under LGPLv2.1+; when it switches to another licence,
that licence will likely be LGPLv2.5[*] rather than LGPLv3.

I don't yet have a precise list of the modules that we'll need, but can
we reasonably assume that Gnulib will accommodate our needs?

Thanks,
Ludovic.

[*] From what I know, LGPLv2.5 will be equivalent to "GPLv2 or LGPLv3".

Minor glitches with `announce-gen'

[Ludovic Courtès]

Hi,

The `NEWS' parsing routine in `announce-gen' seems to be over-specified
in that it expects lines introducing a new version to match
"\* (?:Noteworthy|Major) change".  AFAICS, this is not too common practice
among GNU packages: GnuTLS uses "* Version X.Y.Z (released -MM-DD)",
Guile uses "Changes in X.Y.Z (since X.Y.(Z-1)):", lightning uses "NEWS
FROM VERSION X.Y TO X.(Y+1)", etc.

It'd be nice to either allow a regexp to be passed on the command-line
or to update the "NEWS File" section of the GCS to recommend a specific
format.

Besides, the "Subject" line of the announcement could be made more
human-readable by using the real package name rather than its system
name, e.g., "GNU Hello X.Y released" instead of "hello-X.Y released".

(End of gratuitous nitpicking.  ;-))

Thanks,
Ludovic.

Author list in `version-etc'

[Ludovic Courtès]

Hi,

Currently, `version_etc_va ()' disallows empty author lists.  The GCS do
not mandate it and it can be arguably useful to not list any authors
(e.g., in projects with large `THANKS').

Can the `abort ()' and extraneous newlines be removed?

Thanks,
Ludovic.

PS: I could submit the actual patch but I'd need to assign copyright and
wait...

Multiply exported Gnulib symbols

[Ludovic Courtès]

Hi,

The following issue was brought up recently on the Guile list [0].

Suppose some library uses, e.g., the `strcasecmp' module, which exports
`strcasecmp ()' (assuming the module is actually compiled).  Suppose,
for instance, that an application using said library is also linked
against `strcasecmp'.  Then we may have troubles (depending on how the
application is linked to the library, depending on the OS, depending on
the dynamic linker's options, etc.).

Did you consider such situations already?  Any magic recipes to void
them?  :-)

Thanks,
Ludovic.

[0] http://article.gmane.org/gmane.lisp.guile.devel/6715

Updated user list

[Ludovic Courtès]

Hi,

The attached patch adds Guile (1.9.x) to the user list.

Thanks,
Ludovic.

diff --git a/ChangeLog b/ChangeLog
index d780a41..54fa517 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2007-08-22  Ludovic Courtès  <[EMAIL PROTECTED]>
+
+	* users.txt: Added Guile.
+
 2007-08-22  Eric Blake  <[EMAIL PROTECTED]>
 
 	* tests/test-getdelim.c (main): Use remove, not unlink.
diff --git a/tests/test-canonicalize.sh b/tests/test-canonicalize.sh
old mode 100644
new mode 100755
diff --git a/users.txt b/users.txt
index fa47d01..5802362 100644
--- a/users.txt
+++ b/users.txt
@@ -14,6 +14,7 @@ The following packages appear to be using gnulib and gnulib-tool:
   gpg http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/
   gsasl   http://josefsson.org/cgi-bin/viewcvs.cgi/gsasl/
   gss http://josefsson.org/cgi-bin/viewcvs.cgi/gss/
+  guile   http://cvs.sv.gnu.org/viewvc/guile/guile/guile-core/
   gziphttp://cvs.sv.gnu.org/viewcvs/gzip/gzip/
   hello   http://cvs.sv.gnu.org/viewcvs/hello/hello/
   icoutilshttp://riva.ucam.org/svn/cjwatson/src/debian/icoutils/trunk/icoutils/
@@ -54,7 +55,7 @@ Articles:
 
 -
 
-Copyright (C) 2006 Free Software Foundation, Inc.
+Copyright (C) 2006, 2007 Free Software Foundation, Inc.
 
 This file is free documentation; the Free Software Foundation
 gives unlimited permission to copy and/or distribute it,

Re: Multiply exported Gnulib symbols

[Ludovic Courtès]

Hi,

Bruno Haible <[EMAIL PROTECTED]> writes:

> Three possible issues are known:
>
> 1) guile defining (via gnulib) a symbol called 'strcasecmp', which overrides
>the libc's strcasecmp symbol for libraries that come after libguile in the
>executable's link list or are dynamically loaded.
>
>We work around such problems by doing the override at the preprocessor
>level, rather than at the link level. I.e. on a system where strcasecmp
>is or may be defined at libc level, gnulib does
>  #define strcasecmp rpl_strcasecmp
>and defines rpl_strcasecmp.

>From what I can see, `strcasecmp ()' is precisely one of the few symbols
not handled this way in `string_.h':

  #if ! @HAVE_STRCASECMP@
  extern int strcasecmp (char const *s1, char const *s2);
  #endif

Was it intended or should it be changed to something similar to, e.g.,
the way `strndup' is handled?

> 3) Two different libraries, say, libguile and libgettextpo, using auxiliary
>functions from gnulib. It may happen that libguile and libgettextpo both
>define rpl_strcasecmp, and that this leads to link-time issues.
>
>For this we have nothing prepackaged in gnulib-tool, but there is a
>Makefile snippet that does the necessary #defines, i.e.
>   #define rpl_strcasecmp scm_strcasecmp
>in guile's config.h, and
>   #define rpl_strcasecmp libgettextpo_strcasecmp
>in libgettextpo's config.h. You find this code in the 'config.h' rule in
>
> http://cvs.savannah.gnu.org/viewvc/gettext/gettext-tools/libgettextpo/Makefile.am?revision=1.13&root=gettext&view=text

I second Simon's request to integrate it in Gnulib.  :-)

Thanks for your help!

Ludovic.

Re: Reliance on

[Ludovic Courtès]

Hi,

[EMAIL PROTECTED] (Ludovic Courtès) writes:

> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
>> Another possibility is to generate lib/config.h.in from
>> some-special-name.h.in, say, by some sed script or an autoheader
>> invocation with arguments and output redirection.
>
> Good point.  I ended up using `AC_CONFIG_LINKS' to have a `config.h'
> linked to `some-special-name.h'.

Actually, it just occurred to me that `AC_CONFIG_LINKS' doesn't work
here when builddir != srcdir, because both the source and destination of
the link (namely `some-special-name.h' and `config.h') are under
builddir, whereas `AC_CONFIG_LINKS' looks for the source file under
`srcdir'.

Preparing by hand a `config.h' or `config.h.in' and putting it under
`lib' doesn't work either because it would not get included in the
distribution (I suspect).

Modifying by hand the Gnulib-generated `lib/Makefile.am' doesn't seem
like a viable option either.

Am I overlooking possible solutions or do I really have to rename
`some-special-name.h' to `config.h'?

Thanks,
Ludovic.

Endianness-specific

[Ludovic Courtès]

Hi,

I'm trying to implement functions that convert a string in the current
locale encoding to its UTF-{16,32} representation, for a given
endianness.

`u16-conv-from-enc.c' reads this:

  /* Name of UTF-16 encoding with machine dependent endianness and alignment.  
*/
  #if defined _LIBICONV_VERSION || (__GLIBC__ > 2) || (__GLIBC__ == 2 && 
__GLIBC_MINOR__ >= 2)
  # ifdef WORDS_BIGENDIAN
  #  define UTF16_NAME "UTF-16BE"
  # else
  #  define UTF16_NAME "UTF-16LE"
  # endif
  #endif

... which means we can't portably determine the name of a UTF-{16,32}
for a specific endianness, right?

Then, for portability, I'd end up re-implementing the "#else" part of
`u-conv-from-enc.h'.

Conclusion: `u16_conv_from_encoding ()' and friends really lack an
ENDIANNESS parameter.  Any idea how we could extend the API in
"uniconv.h" to support it?  Perhaps we could add `u{16,32}{be,le}_'
variants of these functions?  Or add, e.g.,

  extern int
  u16_endianness_conv_to_encoding (const char *tocode,
   enum charset_endianness endianness,
   enum iconv_ilseq_handler handler,
   const uint16_t *src, size_t srclen,
   size_t *offsets,
   char **resultp, size_t *lengthp);

Opinions?

Thanks,
Ludovic.

Endianness-aware UTF conversion

[Ludovic Courtès]

Hi Bruno,

Bruno Haible <[EMAIL PROTECTED]> writes:

> Therefore I would recommend to use the mem_cd_iconveh function from the
> 'striconveh' module, with FROMCODE = locale_charset() and TOCODE =
> "UTF-16BE" or "UTF-16LE" (or vice versa). Or mem_iconveh you don't
> want to reuse the conversion descriptors.

That's what I was going to do, but the excerpt of `u16-conv-from-enc.c'
that I quoted made me think that, e.g., "UTF-16BE" and "UTF-16LE" were
only known to work on Glibc >= 2.2:

  /* Name of UTF-16 encoding with machine dependent endianness and alignment.  
*/
  #if defined _LIBICONV_VERSION || (__GLIBC__ > 2) || (__GLIBC__ == 2 && 
__GLIBC_MINOR__ >= 2)
  # ifdef WORDS_BIGENDIAN
  #  define UTF16_NAME "UTF-16BE"
  # else
  #  define UTF16_NAME "UTF-16LE"
  # endif
  #endif

Likewise, `u-conv-from-enc.h' contains alternate code for systems where
`UTF_NAME' is undefined (i.e., typically on non-GNU systems).

Therefore, `mem_iconveh ()' doesn't seem appropriate since there is
AFAIUI no portable way to specify, say, "UTF-16{LE,BE}" as TO_CODESET...
which led me to suggest that we might have to provide endianness-aware
conversion procedures.

Does it clarify things a bit?  :-)

Thanks,
Ludovic.

Re: new module iconv_open-utf

[Ludovic Courtès]

Hi,

Bruno Haible <[EMAIL PROTECTED]> writes:

> Yes, it is clear what you mean. But adding a new API for a thing that
> mem_cd_iconveh should be able to do, just because there is a portability
> problem, is against gnulib's general approach. In gnulib we solve this
> by fixing the portability problem, not by adding new API.
>
> I'm adding a module 'iconv_open-utf' that enhances iconv_open() so that
> it supports conversion between UTF-8 and UTF-{16,32}{BE,LE}. Except on
> platform where iconv is entirely absent or unusable (such as OSF/1 4.0),
> this module allows you to use the mem_iconveh() function for doing conversion
> from an arbitrary encoding to UTF-{16,32}{BE,LE} or vice versa.

Thanks, this solves the problem elegantly!

However, Glibc's manual does not appear to mention the encoding names.

Thanks,
Ludovic.

Re: Gnulib Gentoo package

[Ludovic Courtès]

Hi Sylvain,

Sylvain Beucler <[EMAIL PROTECTED]> writes:

> I noticed 2 issues in your Gnulib Gentoo package:

Thanks for finding it out!

Ludovic.

Re: inline related build failures on MacOS X 10.5

[Ludovic Courtès]

Hi,

Bruno Haible <[EMAIL PROTECTED]> writes:

>   $ gcc -v 2>&1 | tail -1
>   gcc version 4.0.1 (Apple Inc. build 5465)
>
> It appears to be a GCC 4.0.x with some backports from the GCC 4.2 and 4.3
> development.
>
> For 'extern inline', this gcc generates a symbol with global visibility in
> "gcc -std=gnu99" mode, but not in the default mode. The macro that allows to
> distinguish the two cases is '#define __STDC_VERSION__ 199901L' in the
> "gcc -std=gnu99" mode, not defined in the default mode.
>
> Instead of 'extern inline', one cannot use
> 'extern inline __attribute__ ((__gnu_inline__))'
> because that yields warnings:
>   argp-fmtstream.h:231: warning: '__gnu_inline__' attribute directive ignored
> But one can use 'inline'. I.e. __GNUC_STDC_INLINE__ should be defined but
> isn't.

FWIW, I solved it this way in Guile, based on what GNU R does:

  
http://git.sv.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=7dc9ae7179b8b099897f8080b675e2a9c54d388c

This is the very issue Simon mentioned here yesterday or so.

Of course, not compiling in C99 mode solves the problem, and that would
be a reasonable choice since most GNU projects that aim at maximum
portability don't rely on C99 language features.

Thanks,
Ludovic.

Re: stdarg: don't put compiler in gnu99 mode by default

[Ludovic Courtès]

Hi Bruno,

Bruno Haible <[EMAIL PROTECTED]> writes:

> + #ifdef __GNUC_STDC_INLINE__
> + #define __GMP_EXTERN_INLINE extern __inline__ __attribute__ 
> ((__gnu_inline__))

Unfortunately that doesn't work on MacOS X because Apple's GCC (labeled
"4.0") implements C99 inline semantics but

  1. Does not define `__GNUC_STDC_INLINE__'.
  2. Does not support `__gnu_inline__'.

(See my message in the other thread.)

Thanks,
Ludovic.

Re: inline related build failures on MacOS X 10.5

[Ludovic Courtès]

Hi,

Bruno Haible <[EMAIL PROTECTED]> writes:

> Ludovic Courtès wrote:
>> FWIW, I solved it this way in Guile, based on what GNU R does:
>> 
>>   
>> http://git.sv.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=7dc9ae7179b8b099897f8080b675e2a9c54d388c
>
> Do you have information about the compilers with build numbers 5401..5464 ?

Nope, I don't have access to that platform myself.  I took the idea from
https://svn.r-project.org/R/trunk/src/include/Rinlinedfuns.h .

> Btw, when the next version of Apple gcc comes out, based on gcc >= 4.3, and
> defines __GNUC_STDC_INLINE__, this code will still use 'static inline'.
> Whereas it could use
>   extern __inline__ __attribute__ ((__gnu_inline__))
> then, and simple
>   __inline__
> now with the build 5465.

Right, but (i) "static inline" is safe, (ii) who knows what silly
patches Apple will apply to their next GCC series, and (iii) let's not
put too much effort into systems that deliberately break things.

Maybe we should just undefine `__GNUC__' when `__APPLE_CC__' is
defined...

Thanks,
Ludovic.

Re: stdarg: don't put compiler in gnu99 mode by default

[Ludovic Courtès]

Hi Bruno,

Bruno Haible <[EMAIL PROTECTED]> writes:

> The #ifdefs for determining which variant of 'inline' or 'extern inline'
> don't work any more with the Apple GCC compiler on MacOS X.

FWIW, I had reported these issues too:

  http://thread.gmane.org/gmane.comp.lib.gmp.bugs/1979

I can't find the source repository (!) so I don't know whether a similar
patch was applied.

>  #ifdef __GNUC__
> -#ifdef __GNUC_STDC_INLINE__
> +#ifdef __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 2)
>  #define __GMP_EXTERN_INLINE extern __inline__ __attribute__ 
> ((__gnu_inline__))

This would break with GCC < 4.2 because the `gnu_inline' attribute is
supported starting from GCC 4.2.

Thanks,
Ludovic.

Re: stdarg: don't put compiler in gnu99 mode by default

[Ludovic Courtès]

Hi,

Bruno Haible <[EMAIL PROTECTED]> writes:

> Oh, sorry for the duplicate report. Your report does not appear in
> http://lists.gnu.org/archive/html/bug-gmp/
> whereas mine does. And your report appears on gmane, but mine doesn't.
> Are these two different maiing lists??

The Gmane list appears to be [EMAIL PROTECTED]', which is the one
mentioned on http://gmplib.org/ , so these appears to be two different
lists, which is Bad(tm).

> Yeah, that was a syntax error of mine. I meant #if, not #ifdef:
>
> #ifdef __GNUC__
> #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 2)
> #define __GMP_EXTERN_INLINE extern __inline__ __attribute__ ((__gnu_inline__))

Hmm, OK, I had also misread the first `>' as `>='.

Thanks,
Ludovic.

Re: symbol namespace collisions

[Ludovic Courtès]

Hello,

Simon Josefsson <[EMAIL PROTECTED]> writes:

> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> Also, the memrchr module does not support the renaming in config.h that
>> is used to guarantee namespace cleanliness of shared libraries. E.g.
>>   #define memrchr libfoo_memrchr
>
> Interesting, are you using such renaming in some project?  Can gnulib
> generate these re-defines automatically, or do you maintain them
> manually?  How do you test that they work, or know which symbols you
> need to rename?

Any news regarding this?  That's an important point for libraries that
use Gnulib.

Thanks,
Ludovic.

Re: gnulib-cache.m4 readability

[Ludovic Courtès]

Hi,

Eric Blake <[EMAIL PROTECTED]> writes:

> On m4, I'm currently playing with multiple branches, each of which has 
> imported 
> a different set of gnulib modules via 'gnulib-tool --import'.  I'm finding it 
> very difficult to track which modules have been imported to which branches by 
> using a 'git diff' of the various versions of gnulib-cache.m4.

You probably already thought about it, but why not use `wdiff' for that?

Thanks,
Ludovic.

`count-one-bits' -> LGPLv2+

[Ludovic Courtès]

Hi,

Would you be OK to relicense `count-one-bits' under LGPLv2+ for use in
Guile 1.9 (aka. the development branch)?

Thanks,
Ludovic.

Re: `count-one-bits' -> LGPLv2+

[Ludovic Courtès]

Hi,

Eric Blake <[EMAIL PROTECTED]> writes:

> As author, you are entitled to make that change.  And I agree that
> count-one-bits is library quality (since it can often be a thin wrapper
> around a special assembly instruction).  So I went ahead and pushed this
> commit:

Thanks!

Ludo'.

`nstrftime ()' prototype

[Ludovic Courtès]

Hi,

I'm trying to fix a portability bug related to `strftime(3)' [0].  The
`strftime' module doesn't provide `strftime ()' as one would expect but
instead provides `nstrftime ()', with additional arguments:
int ut, int ns.  What are these arguments about?

Thanks,
Ludovic.

[0] https://savannah.gnu.org/bugs/index.php?24130

Re: `nstrftime ()' prototype

[Ludovic Courtès]

Hi Simon,

Simon Josefsson <[EMAIL PROTECTED]> writes:

> That doesn't make much sense to me.  IMHO, the 'strftime' module should
> provide a 'strftime' function.

Agreed.

IIUC, this could be achieved by compiling the file twice: once with
"#define my_strftime" and once without.

> Where is 'nstrftime' defined as a GNU extension, btw?  I can't find it
> in the glibc manual.

It's called `strftime ()' but features extensions compared to POSIX (see
"(libc) Formatting Calendar Time").

Thanks,
Ludo'.

Re: `nstrftime ()' prototype

[Ludovic Courtès]

Hi,

Bruno Haible <[EMAIL PROTECTED]> writes:

> Ludovic Courtès wrote:
>> I'm trying to fix a portability bug related to `strftime(3)' [0].  The
>> `strftime' module doesn't provide `strftime ()' as one would expect
>
> And the gnulib doc is incorrect. Fixing it:

In addition, it doesn't mention any portability problem, but AIX and
Solaris (at least) have a non-C99-compliant behavior (let alone GNU
extensions): https://savannah.gnu.org/bugs/index.php?24130 .

Thanks,
Ludo'.

Re: `nstrftime ()' prototype

[Ludovic Courtès]

Hi Bruno,

Bruno Haible <[EMAIL PROTECTED]> writes:

> Ludovic Courtès wrote:
>> In addition, it doesn't mention any portability problem, but AIX and
>> Solaris (at least) have a non-C99-compliant behavior (let alone GNU
>> extensions): https://savannah.gnu.org/bugs/index.php?24130 .
>
> Can you explain what the portability problem is, preferably with a testcase
> in C? It's not clear to me, from looking at the cited URLs, what you consider
> to be a problem, except that it's something related to "%z".

Yes, `%z' is not honored on all platforms: some don't support it at all
(in which case either "%z" or "" appears in the output), on some
platforms (e.g., AIX) it has different semantics, and on others it seems
to be broken (Solaris?).  Attached is a simple test program (I don't
have access to Solaris and AIX boxes myself so I can't say what the
result's like).

Another portability issue is `%Z', which is apparently not supported on
NetBSD.

Another one is this:

/* POSIX says strftime returns 0 on buffer overrun, but old
   systems (i.e. libc 4 on GNU/Linux) might return `size' in that
   case. */
while ((len = strftime (tbuf, size, myfmt, &t)) == 0 || len == size)

I'm sorry I don't have much more information about the "faulty" systems.
All this is gathered from $GUILE/test-suite/tests/time.test and
$GUILE/libguile/stime.c.

Anyway, I think it motivates the need for a portable `strftime'.  :-)

Thanks,
Ludo'.

#include 
#include 
#include 
#include 

int
main (int argc, char *argv[])
{
  char buf[123];
  size_t size;
  time_t now;
  struct tm *local_now;

  now = time (NULL);

  setenv ("TZ", "GMT", 1);
  local_now = localtime (&now);
  size = strftime (buf, sizeof (buf), "%z", local_now);
  if (strcmp ("+", buf))
{
  /* On AIX, we get "GMT".
 On Solaris, we get "+" (?).  */
  printf ("FAIL: GMT: got `%s'\n", buf);
  return 1;
}

  setenv ("TZ", "EST+5", 1);
  local_now = localtime (&now);
  size = strftime (buf, sizeof (buf), "%z", local_now);
  if (strcmp ("-0500", buf))
{
  /* On AIX, we get "EST".
 On Solaris, we get "+" (?).  */
  printf ("FAIL: EST: got `%s'\n", buf);
  return 2;
}

  return 0;
}

Re: `nstrftime ()' prototype

[Ludovic Courtès]

Hi,

[EMAIL PROTECTED] (Ludovic Courtès) writes:

> I'm trying to fix a portability bug related to `strftime(3)' [0].  The
> `strftime' module doesn't provide `strftime ()' as one would expect but
> instead provides `nstrftime ()', with additional arguments:
> int ut, int ns.  What are these arguments about?

I just remembered I didn't get an answer to the above question.  :-)

(Since I'm too lazy I think I'd rather use `nstrftime ()' than write a
new module providing `strftime ()'.)

Thanks,
Ludo'.

Re: `nstrftime ()' prototype

[Ludovic Courtès]

Hi,

Jim Meyering <[EMAIL PROTECTED]> writes:

> Here's some long-overdue documentation:
>
> From 4bb481aef2793a2cd25d61113d58da42af2bf8a8 Mon Sep 17 00:00:00 2001
> From: Jim Meyering <[EMAIL PROTECTED]>
> Date: Sun, 31 Aug 2008 17:34:24 +0200
> Subject: [PATCH] * lib/strftime.h: Add comments describing the two added 
> arguments.

Thanks!

Ludo'.

Re: `nstrftime ()' prototype

[Ludovic Courtès]

Hi again,

Jim Meyering <[EMAIL PROTECTED]> writes:

> +/* Just like strftime, but with two more arguments:
> +   POSIX requires that strftime use the local timezone information.
> +   When __UTC is nonzero and tm->tm_zone is NULL or the empty string,
> +   use UTC instead.  Use __NS as the number of nanoseconds in the
> +   %N directive.  */
> +size_t nstrftime (char *, size_t, char const *, struct tm const *,
> +   int __utc, int __ns);

Actually, I don't see `%N' documented in the glibc 2.7 manual.  Is it
something newer?

The effect of `brokentime->tm_zone' isn't specified either.

IIUC, glibc's `strftime ()' is equivalent to UTC == 0 and NS == 0,
right?

Thanks,
Ludo'.

[PATCH] Use `AC_C_RESTRICT' in `time'

[Ludovic Courtès]

Hi,

The following patch makes sure `time' uses `AC_C_RESTRICT'.

This fixes compilation at least on MinGW as reported here:

  http://thread.gmane.org/gmane.lisp.guile.bugs/3984

Thanks,
Ludovic.

>From 06dc37c4ee56e9d32bfcb79ace9221c903ade7b2 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ludovic=20Court=C3=A8s?= <[EMAIL PROTECTED]>
Date: Thu, 11 Sep 2008 21:27:23 +0200
Subject: [PATCH] time: Use `AC_C_RESTRICT'.

* modules/time (configure.ac): Add `AC_C_RESTRICT'.  Fixes compilation on
  MinGW.  Reported by Han-Wen Nienhuys <[EMAIL PROTECTED]>.
---
 modules/time |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/modules/time b/modules/time
index 50b07af..8b28dda 100644
--- a/modules/time
+++ b/modules/time
@@ -10,6 +10,7 @@ extensions
 include_next
 
 configure.ac:
+AC_C_RESTRICT
 gl_HEADER_TIME_H
 
 Makefile.am:
-- 
1.6.0

Re: [PATCH] Use `AC_C_RESTRICT' in `time'

[Ludovic Courtès]

Hi,

Eric Blake <[EMAIL PROTECTED]> writes:

> Could it also be a case of not including  before system headers?

You're probably right.  I'm waiting for a confirmation...

Thanks,
Ludo'.

nproc -> LGPL

[Ludovic Courtès]

Hello!

I’d like to use ‘nproc’ in libguile, which is LGPLv3+.  Could you change
the license accordingly?

Thanks,
Ludo’.

Re: nproc -> LGPL

[Ludovic Courtès]

Bruno Haible  writes:

> Glen Lenker wrote:
>> > Glen, do you also agree with Ludo's request?
>> 
>> It is fine with me; nproc is quite libraryish.
>
> OK, I've pushed the license change.

Great, thanks!

Ludo’.

unistr use of undefined macros

[Ludovic Courtès]

Hello,

Commit c98cb289 changed #ifdefs in unistr.in.h to #ifs.  As a
side-effect, this prevents compilation of users of this file, such as
Guile, with ‘-Wundef’:

--8<---cut here---start->8---
In file included from bytevectors.c:43:0:
../lib/unistr.h:161:5: error: "GNULIB_UNISTR_U16_MBTOUC_UNSAFE" is not defined
../lib/unistr.h:184:5: error: "GNULIB_UNISTR_U32_MBTOUC_UNSAFE" is not defined
../lib/unistr.h: In function 'u32_mbtouc_unsafe':
../lib/unistr.h:195:7: error: "CONFIG_UNICODE_SAFETY" is not defined
../lib/unistr.h:199:7: error: "CONFIG_UNICODE_SAFETY" is not defined
../lib/unistr.h: At top level:
../lib/unistr.h:232:5: error: "GNULIB_UNISTR_U16_MBTOUC" is not defined
../lib/unistr.h:255:5: error: "GNULIB_UNISTR_U32_MBTOUC" is not defined
../lib/unistr.h:288:5: error: "GNULIB_UNISTR_U16_MBTOUCR" is not defined
../lib/unistr.h:293:5: error: "GNULIB_UNISTR_U32_MBTOUCR" is not defined
../lib/unistr.h:326:5: error: "GNULIB_UNISTR_U16_UCTOMB" is not defined
../lib/unistr.h:348:5: error: "GNULIB_UNISTR_U32_UCTOMB" is not defined
make[1]: *** [libguile_2.0_la-bytevectors.lo] Error 1
--8<---cut here---end--->8---

In addition, a quick grep through Gnulib suggests that there’s no way
for these macros to be defined:

--8<---cut here---start->8---
$ grep -E '(CONFIG_UNICODE_SAFETY|GNULIB_UNISTR_U[0-9][0-9]_(MBTOUC|UCTOMB))' 
~/src/gnulib/*/*
/home/ludo/src/gnulib/lib/unistr.in.h:#if GNULIB_UNISTR_U16_MBTOUC_UNSAFE || 
HAVE_LIBUNISTRING
/home/ludo/src/gnulib/lib/unistr.in.h:#if GNULIB_UNISTR_U32_MBTOUC_UNSAFE || 
HAVE_LIBUNISTRING
/home/ludo/src/gnulib/lib/unistr.in.h:#  if CONFIG_UNICODE_SAFETY
/home/ludo/src/gnulib/lib/unistr.in.h:#  if CONFIG_UNICODE_SAFETY
/home/ludo/src/gnulib/lib/unistr.in.h:#if GNULIB_UNISTR_U16_MBTOUC || 
HAVE_LIBUNISTRING
/home/ludo/src/gnulib/lib/unistr.in.h:#if GNULIB_UNISTR_U32_MBTOUC || 
HAVE_LIBUNISTRING
/home/ludo/src/gnulib/lib/unistr.in.h:#if GNULIB_UNISTR_U16_MBTOUCR || 
HAVE_LIBUNISTRING
/home/ludo/src/gnulib/lib/unistr.in.h:#if GNULIB_UNISTR_U32_MBTOUCR || 
HAVE_LIBUNISTRING
/home/ludo/src/gnulib/lib/unistr.in.h:#if GNULIB_UNISTR_U16_UCTOMB || 
HAVE_LIBUNISTRING
/home/ludo/src/gnulib/lib/unistr.in.h:#if GNULIB_UNISTR_U32_UCTOMB || 
HAVE_LIBUNISTRING
--8<---cut here---end--->8---

Is it an omission, or am I missing something?

Thanks,
Ludo’.

Re: unistr use of undefined macros

[Ludovic Courtès]

Hi Eric,

Eric Blake  writes:

> On 12/07/2010 02:24 PM, Ludovic Courtès wrote:
>> Hello,
>> 
>> Commit c98cb289 changed #ifdefs in unistr.in.h to #ifs.  As a
>> side-effect, this prevents compilation of users of this file, such as
>> Guile, with ‘-Wundef’:
>
> Unfortunately, that points to a bug in guile.
>
> Gnulib is explicitly documented as being incompatible with -Wundef; and
> while you may choose to use it for the rest of your project, you should
> not use it for gnulib files.

That’s what Guile is doing already.

The error here is when *using*  from libguile, which is
compiled with -Wundef.

> See for example how coreutils sets up two distinct CFLAGS, a stricter
> one for coreutils files in src/ [1] and a looser one for gnulib files in
> lib/ [2]:

I just changed <http://hydra.nixos.org/jobset/gnu/coreutils-master/> so
that Coreutils is built with ‘--enable-gcc-warnings’, and it builds
fine.

However:

--8<---cut here---start->8---
$ grep -r 'unistr.[ch]' . ; echo $?
1
--8<---cut here---end--->8---

(This is in a pristine checkout, without Gnulib in here.)

So no wonder it doesn’t hit that problem.

Thanks,
Ludo’.

Re: PATH_MAX and test-stat.h

[Ludovic Courtès]

Hello,

k...@freefriends.org (Karl Berry) skribis:

> I am aware that conceptually there is no PATH_MAX on Hurd and no
> requirement for it to be a smallish constant, but it seems to me that
> any real-world system has to define PATH_MAX as a reasonable constant
> simply for compatibility with all the code that has been written with
> that assumption over the last 30+ years.

As you probably know, this is an instantiation of the GCS (info
"(standards) Semantics"):

  Avoid arbitrary limits on the length or number of _any_ data structure,
  including file names, lines, files, and symbols, by allocating all data
  structures dynamically.  In most Unix utilities, "long lines are
  silently truncated".  This is not acceptable in a GNU utility.

Thanks,
Ludo’.

getaddrinfo on MinGW

[Ludovic Courtès]

Hello,

The ‘getaddrinfo’ module doesn’t seem to work as advertised ;-) when
cross-building for MinGW.

>From , a file that includes
Gnulib’s  fails to build like this:

--8<---cut here---start->8---
/bin/sh ../libtool  --tag=CC   --mode=compile i686-pc-mingw32-gcc 
-DHAVE_CONFIG_H   -DBUILDING_LIBGUILE=1 -I../../guile-2.0.1.154-f3977 -I.. 
-I../../guile-2.0.1.154-f3977/lib -I../lib 
-I/nix/store/hwd5i31rikwdjmjhxn4d2xwlsxczsg0s-libffi-3.0.9-i686-pc-mingw32/lib/libffi-3.0.9/include
   
-I/nix/store/lqyvgsv21wmf15xnznwv5qi78p59zkfm-libunistring-0.9.3-i686-pc-mingw32/include
 -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wswitch-enum 
-fvisibility=hidden 
-I/nix/store/lli7w1b3kc5nwdwgq9c9ikhdx141bba4-boehm-gc-7.2pre20110122-i686-pc-mingw32/include
   -g -O2 -c -o net_db.lo ../../guile-2.0.1.154-f3977/libguile/net_db.c
libtool: compile:  i686-pc-mingw32-gcc -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 
-I../../guile-2.0.1.154-f3977 -I.. -I../../guile-2.0.1.154-f3977/lib -I../lib 
-I/nix/store/hwd5i31rikwdjmjhxn4d2xwlsxczsg0s-libffi-3.0.9-i686-pc-mingw32/lib/libffi-3.0.9/include
 
-I/nix/store/lqyvgsv21wmf15xnznwv5qi78p59zkfm-libunistring-0.9.3-i686-pc-mingw32/include
 -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wswitch-enum 
-fvisibility=hidden 
-I/nix/store/lli7w1b3kc5nwdwgq9c9ikhdx141bba4-boehm-gc-7.2pre20110122-i686-pc-mingw32/include
 -g -O2 -c ../../guile-2.0.1.154-f3977/libguile/net_db.c -o net_db.o
../../guile-2.0.1.154-f3977/libguile/net_db.c:460:1: error: 'AI_ALL' undeclared 
here (not in a function)
../../guile-2.0.1.154-f3977/libguile/net_db.c:460:1: error: bit-field 
'_gl_verify_error_if_negative' width not an integer constant
../../guile-2.0.1.154-f3977/libguile/net_db.c:482:33: warning: 'struct 
addrinfo' declared inside parameter list
../../guile-2.0.1.154-f3977/libguile/net_db.c:482:33: warning: its scope is 
only this definition or declaration, which is probably not what you want
../../guile-2.0.1.154-f3977/libguile/net_db.c: In function 'scm_from_addrinfo':
../../guile-2.0.1.154-f3977/libguile/net_db.c:490:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:491:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:492:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:493:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:494:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:494:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:496:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:496:3: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c: In function 'scm_getaddrinfo':
../../guile-2.0.1.154-f3977/libguile/net_db.c:614:19: error: storage size of 
'c_hints' isn't known
../../guile-2.0.1.154-f3977/libguile/net_db.c:657:3: warning: implicit 
declaration of function 'getaddrinfo'
../../guile-2.0.1.154-f3977/libguile/net_db.c:665:10: error: dereferencing 
pointer to incomplete type
../../guile-2.0.1.154-f3977/libguile/net_db.c:665:19: warning: left-hand 
operand of comma expression has no effect
../../guile-2.0.1.154-f3977/libguile/net_db.c:666:2: warning: passing argument 
1 of 'scm_from_addrinfo' from incompatible pointer type
../../guile-2.0.1.154-f3977/libguile/net_db.c:482:1: note: expected 'const 
struct addrinfo *' but argument is of type 'struct addrinfo *'
../../guile-2.0.1.154-f3977/libguile/net_db.c:668:7: warning: implicit 
declaration of function 'freeaddrinfo'
../../guile-2.0.1.154-f3977/libguile/net_db.c:614:19: warning: unused variable 
'c_hints'
../../guile-2.0.1.154-f3977/libguile/net_db.c: At top level:
../../guile-2.0.1.154-f3977/libguile/net_db.c:680:1: error: 'EAI_BADFLAGS' 
undeclared here (not in a function)
../../guile-2.0.1.154-f3977/libguile/net_db.c:680:1: error: bit-field 
'_gl_verify_error_if_negative' width not an integer constant
../../guile-2.0.1.154-f3977/libguile/net_db.c: In function 'scm_gai_strerror':
../../guile-2.0.1.154-f3977/libguile/net_db.c:744:3: warning: implicit 
declaration of function 'gai_strerror'
../../guile-2.0.1.154-f3977/libguile/net_db.c:744:3: warning: passing argument 
1 of 'scm_from_locale_string' makes pointer from integer without a cast
../../guile-2.0.1.154-f3977/libguile/strings.h:134:13: note: expected 'const 
char *' but argument is of type 'int'
--8<---cut here---end--->8---

Clearly the AI_ constants and ‘struct addrinfo’ aren’t defined by
.

The relevant part of the ‘configure’ output is [0]:

--8<---cut here---start->8---
checking whether getaddrinfo is declared without a macro... no
checking whether fr

‘iconv’ fails to build on NetBSD 5.1

[Ludovic Courtès]

Hi,

The ‘iconv’ modules fails to build on NetBSD 5.1 (see gcc70 of the GCC
Compile Farm):

--8<---cut here---start->8---
depbase=`echo iconv.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; /bin/ksh 
../libtool  --tag=CC--mode=compile gcc -DHAVE_CONFIG_H  -I. -I../../lib 
-I..   -I/home/ludo/soft/include -I/usr/pkg/include  -fvisibility=hidden 
-I/home/ludo/soft/include   -g -O2 -MT iconv.lo -MD -MP -MF $depbase.Tpo -c -o 
iconv.lo ../../lib/iconv.c && mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../lib -I.. 
-I/home/ludo/soft/include -I/usr/pkg/include -fvisibility=hidden 
-I/home/ludo/soft/include -g -O2 -MT iconv.lo -MD -MP -MF .deps/iconv.Tpo -c 
../../lib/iconv.c  -fPIC -DPIC -o .libs/iconv.o
../../lib/iconv.c:282: error: conflicting types for 'rpl_iconv'
./iconv.h:388: error: previous declaration of 'rpl_iconv' was here
--8<---cut here---end--->8---

The problem is:

--8<---cut here---start->8---
$ grep ICONV_CONST config.status
S["ICONV_CONST"]=""
D["ICONV_CONST"]=" const"
--8<---cut here---end--->8---

Indeed:

--8<---cut here---start->8---
$ grep ICONV_CONST= configure
ICONV_CONST=;
--8<---cut here---end--->8---

So it seems that this snippet doesn’t get expanded:

--8<---cut here---start->8---
m4_ifdef([gl_ICONV_H_DEFAULTS],
  [AC_REQUIRE([gl_ICONV_H_DEFAULTS])
   if test -n "$am_cv_proto_iconv_arg1"; then
 ICONV_CONST="const"
   fi
  ])
--8<---cut here---end--->8---

Ideas?

Thanks,
Ludo’.

Re: ‘iconv’ fails to build on NetBSD 5.1

[Ludovic Courtès]

Hi Bruno,

Bruno Haible  skribis:

>> The ‘iconv’ modules fails to build on NetBSD 5.1 (see gcc70 of the GCC
>> Compile Farm):
>
> Can you show the gnulib-tool invocations that you used when builting
> the tarball of your package? In particular, which of the modules
> 'iconv', 'iconv-h', 'iconv_open' are used, and which --avoid options
> are used?

>From ‘gnulib-cache.m4’:

#   gnulib-tool --import --dir=. --lib=libgnu --source-base=lib --m4-base=m4 
--doc-base=doc --tests-base=tests --aux-dir=build-aux --lgpl=3 
--no-conditional-dependencies --libtool --macro-prefix=gl --no-vc-files accept 
alignof alloca-opt announce-gen autobuild bind byteswap canonicalize-lgpl ceil 
close connect duplocale environ extensions flock floor fpieee frexp full-read 
full-write func gendocs getaddrinfo getpeername getsockname getsockopt 
git-version-gen gitlog-to-changelog gnu-web-doc-update gnupload havelib 
iconv_open-utf inet_ntop inet_pton isinf isnan ldexp lib-symbol-versions 
lib-symbol-visibility libunistring listen locale log1p maintainer-makefile 
malloc-gnu malloca nproc open pipe2 putenv recv recvfrom rename send sendto 
setsockopt shutdown socket stat-time stdlib strftime striconveh string sys_stat 
trunc verify vsnprintf warnings wchar

So it’s only ‘iconv_open-utf’, but it should drag the other iconv*
modules AIUI.

> This shouldn't be either. Can you 'grep serial aclocal.m4' ?

# iconv.m4 serial 11 (gettext-0.18.1)

This is older than the one in the Gnulib repo I used.

(Time passes...)

The bug originates in Nixpkgs/NixOS, which has a wrapper around
‘aclocal’ to make it honor $ACLOCAL_PATH (this is necessary with Nix
since each package is installed in its own path.)  The problem is that
the wrapper would *prepend* the -I flags corresponding to $ACLOCAL_PATH
instead of appending them, hence the bug.

Sorry for the noise!

Thanks,
Ludo’.

Re: Explicit interpreter paths considered harmful

[Ludovic Courtès]

Hi,

Jim Meyering  writes:

> From f8a4d66d651f505d0cd349a7c0be025f1b2e12d0 Mon Sep 17 00:00:00 2001
> From: Jim Meyering 
> Date: Fri, 30 Oct 2009 15:02:02 +0100
> Subject: [PATCH] gitlog-to-changelog: remove #!/usr/bin/perl in favor of more 
> portable...
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Rather than putting #!/usr/bin/perl on the first line,
> start with a variant of what's recommended by "man perlrun" that
> invokes the first "perl" program from your shell's search path.
> * build-aux/gitlog-to-changelog: Replace #!... as above.
> Add a "Local Variables" perl mode setting.
> Prompted by a patch from Ludovic Courtès.
> Improved by Eric Blake.

Works like a charm on NixOS, both with ./gitlog-to-changelog and “perl
gitlog-to-changelog”, thanks!

> ---
>  ChangeLog |   11 +++
>  build-aux/gitlog-to-changelog |7 +--
>  2 files changed, 16 insertions(+), 2 deletions(-)

While you’re at it, can you update the other scripts under ‘build-aux’
that use /usr/bin/perl?

Thanks,
Ludo’.

Re: Explicit interpreter paths considered harmful

[Ludovic Courtès]

Hi Simon,

Simon Josefsson  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Here's a patch.
>>
>> Likewise, ‘pmccabe2html’ assumes /usr/bin/awk, but I’m not sure what to
>> do here:
>
> See the documentation in pmccabe2html -- the recommended way to use the
> script is already using $(AWK).  So I don't think there is any problem,
> is there?

Well, there’s a shebang and the executable bit is set, so it looks like
it can be run as ./pmccabe2html.

>>   - ‘gl_PMCCABE2HTML’ does ‘AC_PROG_AWK’, so we could substitute @AWK@
>> in there.
>
> That leads to having a pmccabe2html.in which is somewhat annoying.

Agreed.

>>   - OTOH, ‘pmccabe2html’ is typically a maintainer script, so I’d rather
>> remove ‘AC_PROG_AWK’ and do something similar to the patch below.
>
> Will that work of invoked with 'awk -f pmccabe2html'?

Yes, of course.

The trick below appears to allow for both ./pmccabe2html and “awk -f
pmccabe2html” (with GNU Awk and Bash):

diff --git a/build-aux/pmccabe2html b/build-aux/pmccabe2html
index 27bb8f3..4fe4c64 100755
--- a/build-aux/pmccabe2html
+++ b/build-aux/pmccabe2html
@@ -1,4 +1,5 @@
-#!/usr/bin/awk -f
+#!/bin/sh
+exec awk -f "$0" "$@"
 # pmccabe2html - pmccabe to html converter
 
 # Copyright (C) 2007, 2008 Free Software Foundation, Inc.

Then I think ‘gl_PMCCABE2HTML’ could be removed altogether, which would
bring the module on par with the other maintainer-only scripts.

What do you think?

Thanks,
Ludo’.

Re: Explicit interpreter paths considered harmful

[Ludovic Courtès]

Excellent, thank you all!

Ludo’.

‘version-etc’ licensing and API

[Ludovic Courtès]

Hello,

I’d like to use ‘version-etc-fsf’ in Guile 1.9+ (for the main
executable), but Guile is LGPLv3+.  Would it be possible to change the
license accordingly?

Besides, ‘version_etc_arn ()’ currently reads this:

--8<---cut here---start->8---
  switch (n_authors)
{
case 0:
  /* The caller must provide at least one author name.  */
  abort ();
--8<---cut here---end--->8---

Since I don’t want to be the one who will designate a few developers as
“authors” of this 16-year old piece of software, I’d prefer to use a
phrase such as “the Guile development team” instead of actual author
names.

One way to do it is to provide this string as the AUTHOR argument to the
function.  Alternatively, if it’s deemed generally useful, the above
snippet could be rewritten along the lines of:

--8<---cut here---start->8---
case 0:
  fprintf (stream, _("Written by the %s development team.\n"),
   package);
  break;
--8<---cut here---end--->8---

What do you think?

Thanks,
Ludo’.

Re: ‘version-etc’ licensing and API

[Ludovic Courtès]

Hi Jim,

Jim Meyering  writes:

> Ludovic Courtès wrote:

>> I’d like to use ‘version-etc-fsf’ in Guile 1.9+ (for the main
>> executable), but Guile is LGPLv3+.  Would it be possible to change the
>> license accordingly?
>
> Sure.  Done.

Thanks.  Can you also change ‘version-etc-fsf’?

Ludo’.

[PATCH] Add ‘gnulib-tool’ support for LGPLv3+

[Ludovic Courtès]

Hello,

The attached patch fixes LGPLv3+ support in ‘gnulib-tool’.

Thanks,
Ludo’.

From 29c308aa797c07f9cc40074338ae6b5e5a290be8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Tue, 17 Nov 2009 21:38:51 +0100
Subject: [PATCH] Add `gnulib-tool --import' support for LGPLv3+.

* gnulib-tool (func_import): Add support for LGPLv3+.
---
 gnulib-tool |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gnulib-tool b/gnulib-tool
index a1e604c..dc59e48 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -2810,7 +2810,7 @@ func_import ()
   case "$lgpl" in
 yes | 3)
   case $license in
-LGPL | LGPLv2+) ;;
+LGPL | LGPLv2+ | LGPLv3+) ;;
 *) func_append license_incompatibilities "$module $license$nl" ;;
   esac
   ;;
-- 
1.6.4.2



pgpN9lMiwC5vZ.pgp
Description: PGP signature

Re: usleep

[Ludovic Courtès]

Hi,

Eric Blake  writes:

> +unsigned int
> +rpl_sleep (unsigned int seconds)
> +{
> +  const unsigned int limit = 49 * 24 * 60 * 60;
> +  while (limit < seconds)
> +{
> +  seconds -= limit;
> +  unsigned int result = sleep (limit);

This declaration-after-statement is a C99 thing.  Isn’t it something
usually avoided in Gnulib?  (I’m asking because I don’t know what the
policy is and I was assuming Gnulib code to be C89.)

Thanks,
Ludo’.

Re: new module 'duplocale'

[Ludovic Courtès]

Hi Bruno,

Bruno Haible  writes:

> glibc unfortunately has a big bug in its duplocale function:
>   
> This module provides a workaround for it. Tested on glibc and MacOS X systems,
> which are AFAIK the only systems so far with a duplocale function.

Excellent, thanks!  Guile now uses the ‘locale’ and ‘duplocale’ modules.

>   const char *base_name = nl_langinfo (_NL_LOCALE_NAME (LC_CTYPE));

This is not thread-safe but I guess there’s no other choice.

On a related note, nl_langinfo_l(3) is broken in current glibc:

  http://sourceware.org/bugzilla/show_bug.cgi?id=11009

Presumably an ‘nl_langinfo_l’ module could build on the ‘duplocale’
module like this:

--8<---cut here---start->8---
char *
rpl_nl_langinfo_l (nl_item item, locale_t locale)
{
  char *result;
  locale_t locale_copy;

  locale_copy = duplocale (locale);
  if (locale_copy != (locale_t) 0)
{
  result = nl_langinfo_l (item, locale_copy);
  freelocale (locale);
}
  else
result = NULL;

  return result;
}
--8<---cut here---end--->8---

What do you think?

Thanks,
Ludo’.

Re: new module 'duplocale'

[Ludovic Courtès]

Hi,

Eric Blake  writes:

> According to Ludovic Courtès on 11/23/2009 4:01 PM:
>>>   const char *base_name = nl_langinfo (_NL_LOCALE_NAME (LC_CTYPE));
>>
>> This is not thread-safe but I guess there’s no other choice.
>
> As is the case with a number of gnulib modules.  But I have been trying to
> document that in the various files; for example, note how
> doc/posix-functions/openat.texi mentions that the replacement is not
> thread-safe.

Yes.  In this case it’s probably safe to say that it’s the programmer’s
responsibility to do proper locking around uses of the global locale.

>> On a related note, nl_langinfo_l(3) is broken in current glibc:
>>
>>   http://sourceware.org/bugzilla/show_bug.cgi?id=11009
>
> For once, I'm tending to agree with Uli - the use of the global locale is
> important for duplocale to create a one-off variant locale, but when it
> comes to all the *_l interfaces, if you want the global locale, then use
> what got returned by duplocale, rather than teaching all the _l interfaces
> to special case the placeholder constant for the global locale.

Hmm, yes.  I think it’d have been much easier like this:

  #define LC_GLOBAL_LOCALE (&_nl_global_locale)

But I guess the reason it’s not done this way is so qthat
‘_nl_global_locale’ can have ‘hidden’ linkage so that the non-_l
variants don’t pay the penalty.  Oh, well.

Thanks,
Ludo’.

Re: new module 'duplocale'

[Ludovic Courtès]

Hi Bruno,

Bruno Haible  writes:

>> >   const char *base_name = nl_langinfo (_NL_LOCALE_NAME (LC_CTYPE));
>> 
>> This is not thread-safe but I guess there’s no other choice.
>
> This code is only used on glibc systems, and nl_langinfo is multithread-safe
> on glibc systems (by code inspection and due to the way it mmaps the locales).
> This means, as long as no thread is calling setlocale, all threads can use
> all locale functions in parallel without interference. If you call setlocale
> while other threads are using locales, you are out for trouble anyway.

OK, good to know.

>> Presumably an ‘nl_langinfo_l’ module could build on the ‘duplocale’
>> module like this:

[...]

> Such code is better written to use uselocale(), which does normally not
> cause memory allocation.

Right.

> You can define such a function for yourself; I agree with Ulrich, Jakub, and
> Eric that this functionality should not be in POSIX and hence also not
> necessarily in gnulib.

Well, as we discussed, an interpretation of
http://www.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html is
that ‘LC_GLOBAL_LOCALE’ can be used anywhere a ‘locale_t’ is expected.

Then again, I understand the performance concerns...

Thanks,
Ludo’.

stdbool issue on Solaris 8 with SunStudio 11

[Ludovic Courtès]

Hello,

Libunistring 0.9.1 fails to build on Solaris with Sun cc and Sun make:

--8<---cut here---start->8---
rm -f unistring/stdbool.h-t unistring/stdbool.h
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
  echo '#if !defined _GL_STDBOOL_H'; \
  if test -f /usr/include/stdbool.h; then \
echo '#if (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95)) || 
defined _AIX'; \
  else \
echo '#if (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95))'; \
  fi; \
  echo '#include '; \
  echo '#else'; \
  cat ../../lib/stdbool.mini.h; \
  echo '#endif'; \
  echo '#endif'; \
} > unistring/stdbool.h-t
cat: cannot open ../../lib/stdbool.mini.h
*** Error code 2
make: Fatal error: Command failed for target `unistring/stdbool.h'
--8<---cut here---end--->8---

Interestingly, GNU make silently ignores the ‘cat’ error, which allow us
to go further but without much success, of course:

--8<---cut here---start->8---
cc -DHAVE_CONFIG_H -DNO_XMALLOC -I. -I../../lib -I..  -I. -I../../lib -I.. 
-I../.. -DIN_LIBUNISTRING -DDEPENDS_ON_LIBICONV=1   -g -c 
../../lib/unicase/cased.c
"../../lib/unicase/cased.h", line 283: warning: initializer does not fit or is 
out of range: 0xff7f
"../../lib/unicase/cased.h", line 283: warning: initializer does not fit or is 
out of range: 0xff7f
"../../lib/unicase/cased.h", line 284: warning: initializer does not fit or is 
out of range: 0x
"../../lib/unicase/cased.h", line 284: warning: initializer does not fit or is 
out of range: 0x
"../../lib/unicase/cased.h", line 284: warning: initializer does not fit or is 
out of range: 0x

[...]

cc -DHAVE_CONFIG_H -DNO_XMALLOC -I. -I../../lib -I..  -I. -I../../lib -I.. 
-I../.. -DIN_LIBUNISTRING -DDEPENDS_ON_LIBICONV=1   -g -c 
../../lib/unicase/empty-prefix-context.c
"../../lib/unicase.h", line 376: syntax error before or at: bool
"../../lib/unicase.h", line 376: warning: undefined or missing type for: bool
--8<---cut here---end--->8---

>From ‘config.log’:

--8<---cut here---start->8---
$ ggrep -A2 stdbool config.log 
configure:18627: checking for stdbool.h that conforms to C99
configure:18720: cc -c -g  conftest.c >&5
"conftest.c", line 62: cannot find include file: 
"conftest.c", line 82: syntax error before or at:  
"conftest.c", line 84: undefined symbol: true
--
| #include 
| #ifndef bool
|  "error: bool is not defined"
--
| our stdbool.h substitute should suffice.  We also test
| this with GCC, where it should work, to detect more
| quickly whether someone messes up the test in the
--
ac_cv_header_stdbool_h=no
ac_cv_header_stdc=yes
ac_cv_header_stdint_h=no
--
STDBOOL_H='stdbool.h'
STDINT_H='stdint.h'
STRIP='strip'
--8<---cut here---end--->8---

Tool versions:

--8<---cut here---start->8---
$ uname -a
SunOS build8s 5.8 Generic_Virtual sun4u sparc SUNW,SPARC-Enterprise-T5220
$ cc -V
cc: Sun C 5.8 Patch 121015-07 2009/04/22
usage: cc [ options] files.  Use 'cc -flags' for details
--8<---cut here---end--->8---

Thanks,
Ludo’.

Re: coreutils-8.2 bug-fix-only release coming soon

[Ludovic Courtès]

Hello,

FWIW the Hydra build farm at TU Deflt[*] now continuously builds
Coreutils from Git using Gnulib from Git[+]:

  http://hydra.nixos.org/jobset/gnu/coreutils-master
  http://hydra.nixos.org/jobset/gnu/coreutils-master/all

Currently 6 of 355 tests fail on GNU/Linux (this could be due to file
system layout assumptions that do not hold on NixOS.)

Thanks,
Ludo’.

[*] See http://nixos.org/hydra/ .  Thanks to Eelco Dolstra and Rob
Vermaas for their help setting it up.

[+] The version number reads “dirty”, but the only change is
‘s|/usr/bin/perl|/right/path/to/perl|g’.

Re: [bug-libunistring] stdbool issue on Solaris 8 with SunStudio 11

[Ludovic Courtès]

Hi Bruno,

Bruno Haible  writes:

> This was a packaging bug in libunistring-0.9.1, and is fixed in
> libunistring-0.9.1.1.

Indeed, thanks.

FYI the Hydra build farm at TU Deflt[*] now continuously builds
libunistring from Git using Gnulib from Git on 3 different platforms:

  http://hydra.nixos.org/jobset/gnu/libunistring
  http://hydra.nixos.org/jobset/gnu/libunistring/all

When everything goes well, a web page with a source tarball, NixOS and
Debian packages, a code coverage report, and the HTML and PDF manual is
generated at:

  http://hydra.nixos.org/view/gnu/libunistring/latest

Thanks,
Ludo’.

[*] http://nixos.org/hydra/

GNU Patch 2.6.1 fails to build on Darwin

[Ludovic Courtès]

Hello,

Patch 2.6.1 fails to build on Darwin with Apple’s “GCC” [0]:

--8<---cut here---start->8---
gcc -std=gnu99 -c  -DHAVE_CONFIG_H 
-Ded_PROGRAM=\"/nix/store/1dk6yj85f9j1manfrd3001az2r7ggb8n-ed-1.4/bin/ed\" 
-DENABLE_MERGE -I. -I./src -I./gl/lib -g -O2 -o gl/lib/strndup.o 
gl/lib/strndup.c
gl/lib/strndup.c: In function 'strndup':
gl/lib/strndup.c:33: warning: implicit declaration of function 'rpl_strnlen'

[...]

gcc -std=gnu99 -o src/patch -g -O2  gl/lib/argmatch.o gl/lib/backupfile.o 
gl/lib/basename.o gl/lib/dirname.o gl/lib/stripslash.o gl/lib/error.o 
gl/lib/exitfail.o gl/lib/strndup.o gl/lib/strnlen.o gl/lib/getopt.o 
gl/lib/getopt1.o gl/lib/hash.o gl/lib/quote.o gl/lib/quotearg.o 
gl/lib/safe-write.o gl/lib/xmalloc.o gl/lib/xstrndup.o gl/lib/full-write.o 
src/merge.o src/inp.o src/maketime.o src/partime.o src/patch.o src/pch.o 
src/quotesys.o src/util.o src/version.o 
i686-apple-darwin9-gcc-4.0.1: gl/lib/strnlen.o: No such file or directory
--8<---cut here---end--->8---

Thanks,
Ludo’.

[0] http://hydra.nixos.org/build/216441/nixlog/1/raw

Re: new snapshot available: coreutils-8.2.52-4db2f

[Ludovic Courtès]

Hi Jim,

Jim Meyering  writes:

> Ludovic Courtès wrote:
>> Surprisingly “make dist” has been failing on Hydra for some time[*]:
>>
>> gcc -std=gnu99  -I.  -g -O2 -c -o exclude.o exclude.c
>> In file included from mbuiter.h:106,
>>  from exclude.c:38:
>> mbchar.h: In function 'mb_width_aux':
>> mbchar.h:241: warning: implicit declaration of function 'wcwidth'
>> In file included from exclude.c:38:
>> mbuiter.h: At top level:
>> mbuiter.h:112: error: expected specifier-qualifier-list before 'mbstate_t'
>> mbuiter.h: In function 'mbuiter_multi_next':
> ...
>> [*] http://hydra.nixos.org/job/gnu/coreutils-master/tarball/all
>
> Thanks for the report.
> wcwidth is supposed to be declared in wchar.h,
> but the above suggests something is not working.

>From what I can see at the URL above the problem was fixed before I
managed to spend time investigating, so that’s cool.  :-)

Thanks,
Ludo’.

Re: [bug-patch] GNU Patch 2.6.1 fails to build on Darwin

[Ludovic Courtès]

Hi Andreas,

Sorry for the late reply.

Andreas Gruenbacher  writes:

> On Monday 11 January 2010 02:45:41 pm Ludovic Courtès wrote:
>> Hello,
>> 
>> Patch 2.6.1 fails to build on Darwin with Apple’s “GCC” [0]:
>
> does the latest version on ftp://alpha.gnu.org/gnu/patch/ work for you?

Yes it does, see http://hydra.nixos.org/build/260036 .

Thanks!

Ludo’.

Bogus getaddrinfo(3) on Darwin 9.2.2

[Ludovic Courtès]

Hello!

The getaddrinfo(3) function appears to have bogus behavior on
‘i386-apple-darwin9.2.2’ (Darwin 9.6 apparently doesn’t have the
problem).  Here’s the test program:

--8<---cut here---start->8---
#include 
#include 
#include 
#include 

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?

Thanks,
Ludo’.

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

[Ludovic Courtès]

Hi Simon,

Simon Josefsson  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hello!
>>
>> The getaddrinfo(3) function appears to have bogus behavior on
>> ‘i386-apple-darwin9.2.2’ (Darwin 9.6 apparently doesn’t have the
>> problem).  Here’s the test program:
>>
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> 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;
>> }
>>
>> 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?
>
> I'm not sure, what exactly makes you believe that other than that there
> is a mismatch between the glibc behaviour?

What I meant to say is that it should return an error because resolving
the ‘does-not-exist’ service fails.

> a NULL nodename:

It’s the same with “127.0.0.1” instead of NULL.

> Which makes me curious about what data is in the returned 'res' variable
> above.  Could you print it?  See tests/test-getaddrinfo.c for printing
> code.

With NULL:

--8<---cut here---start->8---
err = 0 `Unknown error'
flags 0
family 1e
socktype 2
protocol 11
addrlen 28: Found ::
getnameinfo 0: Unknown error
ip ::1
port 0
flags 0
family 1e
socktype 1
protocol 6
addrlen 28: Found ::
getnameinfo 0: Unknown error
ip ::1
port 0
flags 0
family 2
socktype 2
protocol 11
addrlen 16: Found 127.0.0.1
getnameinfo 0: Unknown error
ip 127.0.0.1
port 0
flags 0
family 2
socktype 1
protocol 6
addrlen 16: Found 127.0.0.1
getnameinfo 0: Unknown error
ip 127.0.0.1
port 0
--8<---cut here---end--->8---

With 127.0.0.1:

--8<---cut here---start->8---
err = 0 `Unknown error'
flags 0
family 2
socktype 2
protocol 11
addrlen 16: Found 127.0.0.1
getnameinfo 0: Unknown error
ip 127.0.0.1
port 0
flags 0
family 2
socktype 1
protocol 6
addrlen 16: Found 127.0.0.1
getnameinfo 0: Unknown error
ip 127.0.0.1
port 0
--8<---cut here---end--->8---

The key piece of info here is port = 0, which makes no sense.

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

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

Thanks,
Ludo’.

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

[Ludovic Courtès]

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

> #include 
> #include 
> #include 
> #include 
>
> 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;
> }
>
> 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:

FWIW here’s what other systems do:

  - sparc-sun-solaris2.8: EAI_SERVICE
  - powerpc-ibm-aix5.3.0.0: EAI_NONAME
  - alphaev56-dec-osf5.1b: EAI_SERVICE

Ludo’.

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

[Ludovic Courtès]

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.

>> The key piece of info here is port = 0, which makes no sense.
>
> Right, although I don't see a requirement in the getaddrinfo
> documentation to fail if the service is not known, nor what it actually
> means for a service to be "known" at all.

Well, yeah, it doesn’t seem to be a requirement.

Then again, what would be the point of ‘EAI_NONAME’ and ‘EAI_SERVICE’ if
it weren’t used in such cases?

And what’s the point of returning port = 0 for an unknown service?  It
can only make programs fail gracelessly (e.g., connect() eventually
fails) instead of providing a useful error message.

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

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

(Note that I don’t have access to that machine myself, so I’m relying on
a kind contributor.)

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

Thanks,
Ludo’.

NetBSD 5.0’s lacks AI_* macros

[Ludovic Courtès]

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,
Ludo’.

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

[Ludovic Courtès]

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

> l...@gnu.org (Ludovic Courtès) writes:
>
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> 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;
>> }
>>
>> 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:
>
> FWIW here’s what other systems do:
>
>   - sparc-sun-solaris2.8: EAI_SERVICE
>   - powerpc-ibm-aix5.3.0.0: EAI_NONAME
>   - alphaev56-dec-osf5.1b: EAI_SERVICE
- ia64-hp-hpux11.31: EAI_NONAME

Ludo’.

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: 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: [PATCH] lib/malloca.c, lib/md5.c, lib/sha1.c: don't include unless HAVE_CONFIG_H is defined

[Ludovic Courtès]

Hi,

Simon Josefsson  writes:

> Peter Simons  writes:
>
>> The following patches are necessary to make those modules compile in
>> projects that don't use a  header.
>
> That is generally not supported by gnulib.  The majority of code in
> gnulib assumes there is a config.h already; >95% if my grep is working.

And there’s the ‘sc_prohibit_have_config_h’ target in maint.mk,
presumably because of this.

Thanks,
Ludo’.

Re: gnulib module install

[Ludovic Courtès]

Hi,

Simon Josefsson  writes:

> k...@freefriends.org (Karl Berry) writes:
>
>> What I mean - I wouldn't mind commiting gnulib stuff to VCS, but only
>> if I can omit files generated by autoreconf.
>>
>> FWIW, that is exactly what I do for Texinfo.  It helps my contributors
>> to not spend time dealing with gnulib, and it helps me because it avoids
>> gnulib-skew differences between me and my contributors.
>>
>> Of course, you have to be careful not to commit (and to .vcignore) the
>> files generated by make, such as lib/foo.h when lib/foo.in.h exists.
>>
>> Feel free to peruse the Texinfo source repo
>> (https://savannah.gnu.org/cvs/?group=texinfo) if you're interested.
>>
>> >From reading the manual, I got the impression that it is strictly the
>> either-or approach, 
>>
>> I think the manual (node "VCS Issues") could mention this "middle road"
>> as a possibility.  As far as I can see, you are correct that it only
>> describes the all-or-nothing approach now.
>>
>> If the idea acceptable to the other gnulib folks, I could try to write a
>> patch for it.
>
> Please do,

+1

We use it in Guile for the reasons Karl mentioned, and I also think it
would greatly facilitate bisects.

Thanks,
Ludo’.

Re: C++ libtool build error?

[Ludovic Courtès]

Hello,

Simon Josefsson  writes:

> Recently gnulib added some self-tests written in C++ for otherwise
> C-only modules.  When imported into libidn (otherwise a strictly C
> library), this leads to an error message:
>
> /bin/bash ../libtool --preserve-dup-deps  --mode=link g++ -o 
> test-fcntl-h-c++ test-fcntl-h-c++.o libtests.a ../gl/libgnu.la libtests.a
> libtool: link: unable to infer tagged configuration
> libtool: link: specify a tag with `--tag'
> make[4]: *** [test-fcntl-h-c++] Error 1
> make[4]: Leaving directory `/home/jas/src/libidn/gltests'

For the record, it also breaks “make check” in libunistring with current
Gnulib:

  http://hydra.nixos.org/build/315267

Thanks,
Ludo’.

iconv_open: Build failure with gperf 2.7.2

[Ludovic Courtès]

Hello,

The ‘-m’ gperf option used by the ‘iconv_open’ module isn’t available in
the ancient gperf 2.7.2:

--8<---cut here---start->8---
Making all in lib
rm -f alloca.h-t alloca.h &&  { echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! 
*/';  cat ../../lib/alloca.in.h;  } > alloca.h-t &&  mv -f alloca.h-t alloca.h
rm -f arg-nonnull.h-t arg-nonnull.h &&  sed -n -e '/GL_ARG_NONNULL/,$p'  < 
../../build-aux/arg-nonnull.h  > arg-nonnull.h-t &&  mv arg-nonnull.h-t 
arg-nonnull.h
rm -f c++defs.h-t c++defs.h &&  sed -n -e '/_GL_CXXDEFS/,$p'  < 
../../build-aux/c++defs.h  > c++defs.h-t &&  mv c++defs.h-t c++defs.h
gperf -m 10 ../../lib/iconv_open-aix.gperf > ../../lib/iconv_open-aix.h-t
gperf -m 10 ../../lib/iconv_open-hpux.gperf > ../../lib/iconv_open-hpux.h-t
gperf: invalid option -- m
Usage: gperf 
[-cCdDef[num]FGhHiIjkKlLnNorsStTvWZ7] [input-file]
Try `gperf --help' for more information.
*** Error code 1
gperf: invalid option -- m
Usage: gperf 
[-cCdDef[num]FGhHiIjkKlLnNorsStTvWZ7] [input-file]
Try `gperf --help' for more information.
*** Error code 1
2 errors
*** Error code 1
1 error
*** Error code 2
1 error

$ gperf --version
GNU gperf 2.7.2
--8<---cut here---end--->8---

(This is on GCC Compile Farm’s ‘gcc101’.)

What should be done about it?

Thanks,
Ludo’.

Re: iconv_open: Build failure with gperf 2.7.2

[Ludovic Courtès]

Hi Bruno,

Bruno Haible  writes:

> Ludovic Courtès wrote:
>> The ‘-m’ gperf option used by the ‘iconv_open’ module isn’t available in
>> the ancient gperf 2.7.2:
>
> It is documented in gnulib's DEPENDENCIES file:

Oops, right, I missed that.

>> What should be done about it?
>
> Run gnulib-tool and create your distribution tarballs on a machine that has
> gperf 3.0.1 or newer installed. Preferrably gperf 3.0.4.

That was with a libunistring tarball from
http://hydra.nixos.org/jobset/gnu/libunistring/latest produced with
‘make dist’.

Surprisingly, using BSD make (on FreeBSD) it tries to run gperf, whereas
using GNU make it doesn’t try to (for the same build tree on the same
machine).  Ideas?

Thanks,
Ludo’.

Re: iconv_open: Build failure with gperf 2.7.2

[Ludovic Courtès]

Hi,

Ralf Wildenhues  writes:

> * Ludovic Courtès wrote on Mon, Mar 15, 2010 at 10:13:45AM CET:
>> Surprisingly, using BSD make (on FreeBSD) it tries to run gperf, whereas
>> using GNU make it doesn’t try to (for the same build tree on the same
>> machine).  Ideas?
>
> Without checking the current issue at all, that's almost always due to
> <http://www.gnu.org/software/autoconf/manual/html_node/Make-Target-Lookup.html>

Indeed.  Thanks for the pointer!

Ludo’.

‘pty’ module fails on FreeBSD 7.2

[Ludovic Courtès]

Hi Simon,

[Adding bug-gnu...@gnu.org.]

Simon Josefsson  writes:

> Simon Josefsson  writes:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Next one is this (FreeBSD):
>>>
>>> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -I../lib 
>>> -I../libinetutils-g -O2 -c pty.c
>>> pty.c:24:17: error: pty.h: No such file or directory
>>> pty.c: In function 'startslave':
>>> pty.c:55: warning: implicit declaration of function 'forkpty'
>>> gmake[2]: *** [pty.o] Error 1
>>
>> I recall posting a patch about this to gnulib some time ago, I also
>> tried building inetutils under Mac OS X.  I'll see if I can find it...
>
> Here it is:
>
> http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/19822
>
> But inetutils already have the pty module... can you debug why pty.h
> isn't created?

On Darwin, it’s created and everything goes well.

On FreeBSD, we have this (from <http://hydra.nixos.org/build/325765>):

--8<---cut here---start->8---
checking pty.h usability... no
checking pty.h presence... no
checking for pty.h... no

[...]

checking whether forkpty is declared... no
checking whether forkpty is declared... (cached) no
configure: WARNING: Cannot find forkpty, build will likely fail
checking for library containing forkpty... -lutil

[...]

gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -I../lib 
-I../libinetutils-g -O2 -c pty.c
pty.c:24:17: error: pty.h: No such file or directory
pty.c: In function 'startslave':
pty.c:55: warning: implicit declaration of function 'forkpty'
gmake[2]: *** [pty.o] Error 1
--8<---cut here---end--->8---

and lib/pty.h isn’t created, presumably because $(PTY_H) remains empty.

Looking at pty.m4, I’m wondering whether the second
‘AC_CHECK_DECL([forkpty]...])’ is actually performed; it seems that
‘configure’ just reuses the value from the previous check.  Thus, if
‘forkpty’ is declared in , it’s never found.

Thanks,
Ludo’.

Re: ‘pty’ module fails on FreeBSD 7.2

[Ludovic Courtès]

Hi Ralf,

Ralf Wildenhues  writes:

> * Ludovic Courtès wrote on Tue, Mar 16, 2010 at 10:52:11AM CET:
>> checking whether forkpty is declared... no
>> checking whether forkpty is declared... (cached) no
>
>> Looking at pty.m4, I’m wondering whether the second
>> ‘AC_CHECK_DECL([forkpty]...])’ is actually performed; it seems that
>> ‘configure’ just reuses the value from the previous check.  Thus, if
>> ‘forkpty’ is declared in , it’s never found.
>
> Yes, you have to unset the cache variable before the second test,
> ac_cv_have_decl_forkpty.

Then I think this patch should fix it:

2010-03-17  Ludovic Courtès   (tiny change)

* m4/pty.m4: Unset $ac_cv_have_decl_forkpty before the second
`AC_CHECK_DECL' invocation.

diff --git a/m4/pty.m4 b/m4/pty.m4
index 1d8616d..35ff929 100644
--- a/m4/pty.m4
+++ b/m4/pty.m4
@@ -17,6 +17,7 @@ AC_DEFUN([gl_PTY],
   if test $ac_cv_header_pty_h != yes; then
 AC_CHECK_DECL([forkpty],,, [[#include ]])
 if test $ac_cv_have_decl_forkpty = no; then
+  unset ac_cv_have_decl_forkpty
   AC_CHECK_DECL([forkpty],,, [[#include ]])
   if test $ac_cv_have_decl_forkpty = no; then
 AC_MSG_WARN([[Cannot find forkpty, build will likely fail]])

Thanks,
Ludo’.


pgplhQbS0OBcP.pgp
Description: PGP signature

Re: ‘pty’ module fails on FreeBSD 7.2

[Ludovic Courtès]

Hi Simon,

Simon Josefsson  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi Ralf,
>>
>> Ralf Wildenhues  writes:
>>
>>> * Ludovic Courtès wrote on Tue, Mar 16, 2010 at 10:52:11AM CET:
>>>> checking whether forkpty is declared... no
>>>> checking whether forkpty is declared... (cached) no
>>>
>>>> Looking at pty.m4, I’m wondering whether the second
>>>> ‘AC_CHECK_DECL([forkpty]...])’ is actually performed; it seems that
>>>> ‘configure’ just reuses the value from the previous check.  Thus, if
>>>> ‘forkpty’ is declared in , it’s never found.
>>>
>>> Yes, you have to unset the cache variable before the second test,
>>> ac_cv_have_decl_forkpty.
>>
>> Then I think this patch should fix it:
>
> Applied, let's see if it helps.

Apparently it doesn’t: http://hydra.nixos.org/build/327435 .

I’ve checked this:

--8<---cut here---start->8---
$ uname -rs
FreeBSD 8.0-RELEASE
$ grep forkpty /usr/include/*.h
/usr/include/libutil.h:int  forkpty(int *_amaster, char *_name,
--8<---cut here---end--->8---

But the build farm uses FreeBSD 7.2, where things could be different.

Thanks,
Ludo’.

Re: sys_ioctl, sys_select: fix link errors

[Ludovic Courtès]

Hi Bruno,

Bruno Haible  writes:

> 2010-03-28  Bruno Haible  
>
>   Fix link errors on mingw.
>   * lib/sys_ioctl.in.h (ioctl): Fix declaration idiom.
>   * modules/sys_ioctl-tests (Makefile.am): Link test-sys_ioctl-c++ with
>   $(LIBSOCKET).
>   * modules/sys_select-tests (Makefile.am): Link test-sys_select-c++ with
>   $(LIBSOCKET).

This patch appears to break Inetutils bootstrapping:

  http://hydra.nixos.org/build/335490

Thanks,
Ludo’.

Re: sys_ioctl, sys_select: fix link errors

[Ludovic Courtès]

Hi Bruno,

Bruno Haible  writes:

>> >* lib/sys_ioctl.in.h (ioctl): Fix declaration idiom.
>> 
>> This patch appears to break Inetutils bootstrapping:
>> 
>>   http://hydra.nixos.org/build/335490
>
> Thanks for the quick report. This should fix it. The fix is modeled after the
> gettimeofday, forkpty, openpty wrappers by Eric.

It does the trick, yes.  Thanks!

Ludo’.

Re: const local variables

[Ludovic Courtès]

Hello,

Paul Eggert  writes:

> All other things being equal, we should be encouraging a functional
> style in which most local variables and parameters are never modified
> once set.

Agreed.  How about adding something along these lines in the GCS?

Thanks,
Ludo’.