Re: fstatat.c broken in OpenBSD 4.6

[Jim Meyering]

Mats Erik Andersson wrote:
> lördag den 29 september 2012 klockan 19:16 skrev Jim Meyering detta:
>> Mats Erik Andersson wrote:
>> >
>> >   fstatat.c:26:10: #include expects "FILENAME" or 
>> >
>> That appears to be due to a typo.
>> Can you confirm the following fix solves the problem?
>
> Works well. The misprint explains why also removal was effective.

Thanks for confirming that.

Re: lib-ld.m4 duplicates libtool.m4's --with-gnu-ld

[Bruno Haible]

Hi Simon,

> I noticed this problem that was reported to gnutls some time ago.  It
> seems lib-ld.m4 contains a copy of some code from libtool.m4

The reason is that
1) module 'havelib' does not want to assume the use of libtool
   (remember, 'havelib' is about _using_ shared libraries, not _creating_
   them).
2) libtool's LT_PATH_LD wasn't documented in libtool version 1.5.22, which
   is the minimum version of libtool supported by gnulib.

> from libtool version 1.4.  Is there any reason for this?  Could lib-ld.m4
> assume more modern libtool.m4 instead?

Here's a rebase from libtool 1.4 to libtool 2.4. Mostly cosmetics.


2012-09-30  Bruno Haible  

havelib: Follow libtool developments.
* m4/lib-ld.m4: Rebase on libtool.m4 from libtool-2.4.
Suggested by Simon Josefsson.

--- m4/lib-ld.m4.orig   Sun Sep 30 23:20:57 2012
+++ m4/lib-ld.m4Sun Sep 30 23:20:05 2012
@@ -1,33 +1,39 @@
-# lib-ld.m4 serial 5 (gettext-0.18.2)
+# lib-ld.m4 serial 6
 dnl Copyright (C) 1996-2003, 2009-2012 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
 dnl with or without modifications, as long as this notice is preserved.
 
 dnl Subroutines of libtool.m4,
-dnl with replacements s/AC_/AC_LIB/ and s/lt_cv/acl_cv/ to avoid collision
-dnl with libtool.m4.
+dnl with replacements s/_*LT_PATH/AC_LIB_PROG/ and s/lt_/acl_/ to avoid
+dnl collision with libtool.m4.
 
-dnl From libtool-1.4. Sets the variable with_gnu_ld to yes or no.
+dnl From libtool-2.4. Sets the variable with_gnu_ld to yes or no.
 AC_DEFUN([AC_LIB_PROG_LD_GNU],
 [AC_CACHE_CHECK([if the linker ($LD) is GNU ld], [acl_cv_prog_gnu_ld],
-[# I'd rather use --version here, but apparently some GNU ld's only accept -v.
+[# I'd rather use --version here, but apparently some GNU lds only accept -v.
 case `$LD -v 2>&1  /dev/null 2>&1; do
+[[\\/]]* | ?:[[\\/]]*)
+  re_direlt='/[[^/]][[^/]]*/\.\./'
+  # Canonicalize the pathname of ld
+  ac_prog=`echo "$ac_prog"| sed 's%%/%g'`
+  while echo "$ac_prog" | grep "$re_direlt" > /dev/null 2>&1; do
 ac_prog=`echo $ac_prog| sed "s%$re_direlt%/%"`
   done
   test -z "$LD" && LD="$ac_prog"
@@ -78,23 +85,26 @@
 fi
 AC_CACHE_VAL([acl_cv_path_LD],
 [if test -z "$LD"; then
-  IFS="${IFS=  }"; ac_save_ifs="$IFS"; IFS="${IFS}${PATH_SEPARATOR-:}"
+  acl_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
   for ac_dir in $PATH; do
+IFS="$acl_save_ifs"
 test -z "$ac_dir" && ac_dir=.
 if test -f "$ac_dir/$ac_prog" || test -f "$ac_dir/$ac_prog$ac_exeext"; then
   acl_cv_path_LD="$ac_dir/$ac_prog"
   # Check to see if the program is GNU ld.  I'd rather use --version,
-  # but apparently some GNU ld's only accept -v.
+  # but apparently some variants of GNU ld only accept -v.
   # Break only if it was the GNU/non-GNU ld that we prefer.
-  case `"$acl_cv_path_LD" -v 2>&1 < /dev/null` in
+  case `"$acl_cv_path_LD" -v 2>&1 

Re: unistd.h has to be included twice to avoid compile errors on MinGW

[Bruno Haible]

Hi,

Philip Nienhuis wrote on 2012-08-26:
> See this thread:
> http://lists.gnu.org/archive/html/bug-gnulib/2011-01/msg00473.html
> 
> When compiling code invoking gnulib under MinGW, the statement
>#include 
> has to present in duplo to avoid certain errors of the kind: "... is not 
> a member of 'gnulib'" (where ... could be e.g., gethostname, isatty, 
> unlink, etc).
> 
> This issue has not been solved until now; so here's again a request to 
> look into it.

This is a complicated issue that we cannot solve by guesswork. What we need
is an unambiguous step-by-step "how to reproduce" recipe. What source code
file to compile (or alternatively, what sources to download), with which
compiler to configure it (there are many mingw versions floating around), etc.

Bruno

Re: diffutils test failure on nixos/hydra's solaris build

[Bruno Haible]

Jim Meyering wrote on 2012-08-28:
> FAIL: test-localeconv (exit: 262)
> =
> 
> test-localeconv.c:41: assertion failed
> 
> which corresponds to this line:
> 
> $ cat -n tests/test-localeconv.c|grep -B6 41
> 35{
> 36  struct lconv *l = localeconv ();
> 37
> 38  ASSERT (STREQ (l->decimal_point, "."));
> 39  ASSERT (STREQ (l->thousands_sep, ""));
> 40  #if !defined __FreeBSD__
> 41  ASSERT (STREQ (l->grouping, ""));
> 

It's easy to work around the failure. Since that particular test
is already exempted on FreeBSD, it's not a big deal to also disable
it on Solaris 11.


2012-09-30  Bruno Haible  

localeconv tests: Avoid test failure on OpenIndiana.
* tests/test-localeconv.c (main): On OpenIndiana (a Solaris 11 variant)
skip the 'grouping' and 'mon_grouping' tests.
Reported by Jim Meyering.

--- tests/test-localeconv.c.origSun Sep 30 23:36:32 2012
+++ tests/test-localeconv.c Sun Sep 30 23:33:23 2012
@@ -37,13 +37,13 @@
 
 ASSERT (STREQ (l->decimal_point, "."));
 ASSERT (STREQ (l->thousands_sep, ""));
-#if !defined __FreeBSD__
+#if !(defined __FreeBSD__ || defined __sun)
 ASSERT (STREQ (l->grouping, ""));
 #endif
 
 ASSERT (STREQ (l->mon_decimal_point, ""));
 ASSERT (STREQ (l->mon_thousands_sep, ""));
-#if !defined __FreeBSD__
+#if !(defined __FreeBSD__ || defined __sun)
 ASSERT (STREQ (l->mon_grouping, ""));
 #endif
 ASSERT (STREQ (l->positive_sign, ""));

Re: gnulib doesn't add lib/spawn.h to .gitignore?

[Bruno Haible]

[Dropping bug-coreutils from CC]

Hi Stefano,

> OK, this is a minor annoyance rather than a real bug, but I guess
> reporting it won't hurt.
> 
> In GNU coreutils, the gnulib-provided 'bootstrap' script fails to add
> the generated file 'lib/spawn.h' to the .gitignore in 'lib/':
> 
>   $ ./bootstrap && ./configure && make
>   ... [all is OK]
>   $ git status
>   ...
>   # Untracked files:
>   #   (use "git add ..." to include in what will be committed)
>   #
>   #   lib/spawn.h
>   nothing added to commit but untracked files present (use "git add" to track)
>   $ grep spawn lib/.gitignore
>   /spawn-pipe.c
>   /spawn-pipe.h
>   /spawn.in.h
>   /spawn_faction_addclose.c
>   /spawn_faction_adddup2.c
>   /spawn_faction_addopen.c
>   /spawn_faction_destroy.c
>   /spawn_faction_init.c
>   /spawn_int.h
>   /spawnattr_destroy.c
>   /spawnattr_init.c
>   /spawnattr_setflags.c
>   /spawnattr_setsigmask.c
>   /spawni.c
>   /spawnp.c
>   /w32spawn.h

I believe that the right choice of which files to put under version
control and which files to declare gitignored, in a project that uses
the GNU Autotools, is the following:

Because releases are rolled through automake's "make distcheck", unused files
can lie around in the working checkout. A separate "-clean" checkout is used
which should not contain modifications nor unused files.

   in  in
  Committed.gitignore.git/info/exclude

SourceY N   N

gnulib-cache.m4   Y N   N

Brought in by autotools,  N Y   N
gnulib-tool

Generated by autotoolsN Y   N

Generated by "make" and   N Y   N
distributed (i.e. kept by
"make distclean")

Generated by "make" and   N N   Y
not distributed (i.e. erased by
"make distclean")

Editor backup files   N Y   N


Currently gnulib-tool augments .gitignore for the files categorized as
"Brought in by autotools, gnulib-tool".

An option that would tell gnulib-tool to add also the files "Generated by
"make" and distributed" could be useful, for modules that have a
MAINTAINERCLEANFILES augmentation (such as 'parse-datetime' or 'iconv_open').

But what you are talking about is the category "Generated by "make" and
not distributed". I believe it depends on project policy whether such files
go into .gitignore. To get at this list of files, gnulib-tool should collect
the intersection of BUILT_SOURCES and MOSTLYCLEANFILES of all modules, right?

Bruno

Re: [PATCH 3/9] tls-tests: omit unnecessary 'inline'

[Bruno Haible]

Hi Paul,

> Simplicity and portability trump efficiency in test cases.

Agreed. Thanks for the change.

Bruno

Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

[Bruno Haible]

Hi Paul,

> * m4/sockets.m4 (gl_SOCKETS):
> * m4/sys_stat_h.m4 (gl_HEADER_SYS_STAT_H):
> Remove AC_C_INLINE.  Here, 'inline' is used only in MSVC
> environments where it's already guaranteed to work

Nope. MSVC does *not* support 'inline' for functions.

Quoting :
  "The inline keyword is available only in C++.
   The __inline and __forceinline keywords are available in both C and C++.
   For compatibility with previous versions, _inline is a synonym for __inline."

This is what I see with MSVC 9:

$ cat foo.c
inline int square (int x)
{
  return x * x;
}

$ cl -nologo foo.c -c  
foo.c
foo.c(1) : error C2054: Nach 'inline' muss '(' folgen
foo.c(2) : error C2085: 'square': Nicht in der formalen Parameterliste enthalten
foo.c(2) : error C2143: Syntaxfehler: Es fehlt ';' vor '{'

$ cl -nologo foo.c -c -Dinline=_inline
foo.c

$ cl -nologo foo.c -c -Dinline=__inline
foo.c

So, for functions, in C mode, it does understand '_inline' and '__inline'
but not 'inline'.

Bruno

Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

[Paul Eggert]

On 09/30/2012 03:22 PM, Bruno Haible wrote:
> Nope. MSVC does *not* support 'inline' for functions.

Thanks for catching that.  Sorry, I thought they
supported it, it's been in the standard for what,
12 years now?  Anyway, I reverted that change.

Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

[Michael Goffioul]

On Sun, Sep 30, 2012 at 7:24 PM, Paul Eggert  wrote:

> On 09/30/2012 03:22 PM, Bruno Haible wrote:
> > Nope. MSVC does *not* support 'inline' for functions.
>
> Thanks for catching that.  Sorry, I thought they
> supported it, it's been in the standard for what,
> 12 years now?
>

Unfortunately, MSVC shamefully sticks to C89, with very little of C99
supported. The main argument being that you can achieve the same in C++ and
that there's no customer request, so they won't put any effort in it.

Michael.