Re: bugs in dirname module

[Bruno Haible]

Eric Blake wrote:
> > Why not use this instead?
> >
> > #define c_isalpha(c) (((unsigned int) (c) | ('a' - 'A')) - 'a' <= 'z' -
> > 'a')
>
> This is a slick definition, but it is different than what c-ctype.h
> provided, and that definition was not guarded.  Bruno, would you accept
> the following patch to c-ctype, so that the order between "c-ctype.h" and
> my patched "dirname.h" won't matter?
>   (c_isalpha) [C_CTYPE_ASCII]: Guard against redefinition.

No, I don't think that would be good: It's not dirname.h's job to define
macros for testing character properties. dirname.h should only export
things related to filenames and pathnames. Any other macro in it should
be made private, i.e. renamed to something like _DIRNAME_ISALPHA or so,
so that it is clear that it is not meant to be used for other purposes.

> An alternative to editing c-ctype is naming the dirname.h version
> IS_DRIVE_LETTER instead of c_isalpha.

Yes, this is much better. Also it reflects more closely what the macro is
used for.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: Separate csharpcomp.sh, and a license problem

[Bruno Haible]

Simon Josefsson wrote:
> After including the csharpcomp module in libidn, I realized I don't
> need any of the C code in that module.  I just need csharpcomp.sh.in,
> csharp.m4 and csharpcomp.m4.
>
> How about installing the following csharpcomp-script module for those
> files, and patching the csharpcomp module to depend on the former
> module?
>
> Even with this, I can't use this in Libidn.  The reason was silly: the
> "License:" says GPL, but Libidn required LGPL.  I have no problem with
> the script staying GPL, it is only used during compilation, so it
> won't affect the C# code license (which incidentally is GPL anyway;
> only the C library is LGPL, that's why I use gnulib-tool --lgpl for
> libidn).
>
> Is there any way to express this license situation?
>
> How about changing the License of the csharpcomp-script module to
> "helper-GPL", and make "helper-GPL" LGPL-compatible, as far as
> gnulib-tool is concerned?
>
> To clarify: gnulib-tool should NOT alter the GPL license template in
> csharpcomp.sh.in here.  I feel the script should stay GPL.  My point
> is to make it possible to use the script to build LGPL material.

I agree with all this. I've changed gnulib-tool to accept modules whose
license is "GPLed build tool", and created a csharpcomp-script and
javacomp-script module under this license. This should make it clear
that - unlike the automake-provided build tools but exactly like
texinfo.tex - the tool is GPL but its use as build tool does not
infect your source with GPL.


2005-12-02  Bruno Haible  <[EMAIL PROTECTED]>

* gnulib-tool (func_import): Accept GPLed build tool modules when
--lgpl is given.
* modules/csharpcomp-script: New file.
* modules/csharpcomp: Depend on it.
* modules/javacomp-script: New file.
* modules/javacomp: Depend on it.
Suggested by Simon Josefsson.


Also I updated the csharpcomp.sh.in script with a bugfix from GNU gettext.

Thanks for your suggestion!

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: Separate csharpcomp.sh, and a license problem

[Bruno Haible]

Simon Josefsson wrote:
> > * modules/csharpcomp: Depend on it.
> > * modules/javacomp: Depend on it.
>
> These two patches were forgotten, apparently.

Oops, fixed. Sorry, I'm constantly in a hurry these days.

> I'm now using csharpcomp to build the Libidn C# port.
>
> How does javacomp relate to the automake Java support?

- automake's support uses only gcj, ignoring the "javac" and "jikes"
  commands.
- It completely ignores CLASSPATH issues.

> How about merging the
> javacomp script with automake?  That would make it possible to use
> non-gcj java compilers too.  If that is done, perhaps also supporting
> C#, through csharpcomp, in automake is simple.

Supporting C# with csharpcomp would even be simpler, because on the
Java side there are three possibilities at configure time (no Java
support at all, Java support for creating jars, Java support for creating
jars and executables) compared to only two possibilities for C#.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: Separate csharpcomp.sh, and a license problem

[Bruno Haible]

Simon Josefsson wrote:
> Shouldn't csharpcomp-script and javacomp-script also invoke
> AC_CONFIG_FILES on the scripts?  I need to do that manually now, and
> gnulib-tool didn't tell me about it.
>
> I can't come up with a simple patch -- the AC_CONFIG_FILES statement
> would have to include the directory somehow.

You can probably assume that the .sh.in file is in the build-aux dir,
i.e. in $top_srcdir/$ac_aux_dir, and that the .sh file will be put into
the $top_builddir. Like for libtool for example. This should
simplify things.

> Should we add another line in the modules-file, i.e.:
>
> Config-files:
> lib/csharpcomp.sh

I don't think this is needed.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: Separate csharpcomp.sh, and a license problem

[Bruno Haible]

Simon Josefsson wrote:
> > - automake's support uses only gcj, ignoring the "javac" and "jikes"
> >   commands.
>
> Right.
>
> > - It completely ignores CLASSPATH issues.
>
> Which, automake or javacomp?

I meant, automake.

> I'd like to support javac and jikes.

javacomp supports it.

> Does javacomp support building *.jar files?

You don't need javacomp for that. A simple

   $(JAR) cf $@ foo*.class

in the Makefile.am, coupled with a

   AC_CHECK_PROG(JAR, jar, jar)

in the configure.ac, does it.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Don't bother checking for unistd.h

[Bruno Haible]

Stepan Kasal wrote on 2005-10-25:
>   would the following patch be welcome?
> 
> 2005-10-24  Stepan Kasal  <[EMAIL PROTECTED]>
> 
> * c-stack.c, copy-file.c, execute.c, fatal-signal.c, findprog.c,
> getlogin_r.c, getlogin_r.h, pagealign_alloc.c, pipe.c, pipe.h,
> progreloc.c, wait-process.h: Don't bother checking for unistd.h.

For copy-file.c, execute.c, fatal-signal.c, findprog.c, pipe.c, pipe.h,
progreloc.c, wait-process.h this is not welcome, because these modules
are used in GNU gettext and sometimes people still build GNU gettext with
the MSVC compiler.

For c-stack.c, getlogin_r.c, getlogin_r.h, pagealign_alloc.c, I'm neutral.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: findutils-4.2.26 build error on HP-UX 10.20

[Bruno Haible]

Peter Fales wrote on 2005-11-22:
> The error message occurs while building gnulib/lib (as part of
> findutils-4.2.26):
>
> $ make
> make  all-am
> make[1]: Entering directory
> build/output/expmake/build/gnucoresrc/build/findutils/gnulib/lib'
> /opt/exp/gnu/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../.. -O -c mbchar.c In
> file included from mbchar.c:24:
> mbchar.h:160:20: wctype.h: No such file or directory
> make[1]: *** [mbchar.o] Error 1
> make[1]: Leaving directory
> build/output/expmake/build/gnucoresrc/build/findutils/gnulib/lib' make: ***
> [all] Error 2
> $

The problem is that findutils/gnulib/lib/Makefile.am contains the line

  libgnulib_a_SOURCES += mbchar.h mbchar.c

coming from gnulib's module/modules/mbchar. This has been fixed in gnulib
on 2005-09-26. After the findutils maintainer uses "gnulib-tool --update",
the problem should go away.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] style question - const char *

[Bruno Haible]

Paul Eggert wrote on 2005-11-18:
> I prefer putting type qualifiers like "const" after the types they
> modify, as that's more consistent.  ...
>
> Not everyone agrees with this style, but I suspect this is often
> because they haven't thought through the consistency issues.

While I know that "char const *" is more consistent, I prefer to use
"const char *", because it's an idiom that most C programmer know and
understand. Like the parsing of natural language, the parsing of a C
program by a human is largely based on idioms, and "const char *"
meaning "string" is such an idiom.

It's the same reason why I use 'bool' (rather than 'unsigned char' or
'_Bool') to denote a boolean value: it's the common idiom for this type,
therefore using that idiom - rather than rolling your own - makes programs
more readable.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: findutils 4.2.27 on IRIX 5.3

[Bruno Haible]

Georg Schwarz wrote:
> > findutils 4.2.27 does not compile on IRIX 5.3:
>
> [...]
>
> > cfe: Error: ./mbchar.h: 157: Cannot open file wchar.h for #include
>
> [...]
>
> > IRIX 5.3 does not have wchar.h.

That was a bug in gnulib before 2005-09-26. Now, I believe everything is
fine in gnulib: wchar.h is used unconditionally by mbchar.h, but mbchar.h
is documented to be only included when HAVE_WCHAR_H && HAVE_WCTYPE_H, and
mbchar.c is to be compiled only on platforms that support it (mbchar.m4
as of 2005-09-26).

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] gnulib-tool --lgpl exception for self tests?

[Bruno Haible]

Simon Josefsson wrote on 2005-10-25:
> I'm using gnulib-tool --lgpl in some projects.  All of the *-tests
> modules that I wrote recently are GPL.  There isn't really a need for
> these self tests to be available under LGPL, but gnulib-tool complain
> because I used --lgpl.  I think it would be fine to include GPL self
> tests in a LGPL project, so I want gnulib-tool to deal with this
> scenario.

I don't think it makes a big difference for a test to be under GPL
versus LGPL. While normal code can be copied from one package to
another, tests are so closely tied to the code they test that there
is not much reuse possible. Furthermore test code is rarely stored
in executables or libraries for which the GPL would make a difference.

Since it is easier to understand when all files in a package are
under the same license, rather than to say "lib/ is under LGPL and
tests/ under GPL", my vote is to distribute the tests under the same
license as the code.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: inet_ntop fix for mingw32

[Bruno Haible]

Simon,

Yoann Vandoorselaere wrote on 2005-10-25:
> As you point out above, the untested netinet/in.h and sys/socket.h
> change might lead to compilation warnings/failure on some systems. It
> would be a good idea to check this specific change on OpenBSD 3.4 for
> example.

I now checked the current inet_ntop module on OpenBSD 3.4.
- It fails to compile because it is missing the dependency to the 'restrict'
  module. Simon, seems you forgot to commit the modules/inet_ntop patch?
- netinet/in.h is currently not included by inet_ntop.h and is not needed.
- sys/socket.h is currently included. It is not needed on OpenBSD 3.4.
  But it is needed for 'socklen_t' to be defined portably, I think - look
  at socklen.m4.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Use of bison

[Bruno Haible]

Mark D. Baushke wrote on 2005-12-30:
> For what it may be worth, the CVS project has a
> forked copy of the GNULIB bison.m4 which uses
> bison-missing until such time as automake-1.10 is
> released when it will no longer be an issue.

Which macro is used, depends on whether the generated .c file is put into
the project's CVS and regularly updated. If it is, then if 'bison' is not
found, it can default to ':'. (This is what GNU gettext does in gettext.m4.)
If not, then anyone without 'bison' can not build the package or will run
into mysterious crashes due to an outdated .c file. (This is the case for
the majority of projects, since the majority opinion is that generated files
don't belong in CVS.)

We could provide a gnulib-tool option that changes the default in bison.m4
to ':'. But what would be the consequence? People would use this option
because it's more comfortable, and when they forget to regularly update their
.c files, mysterious bugs appear. So all in all, I think the current
bison.m4 is the best.

> +dnl later, as those avoid generating .c files from .y when not in maintainer
> +dnl mode.

Maintainer mode is not a good thing. It creates barriers between first-class
developers and second-class developers. Educating second-class developers how
to become first-class developers is more desirable, IMO.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Symbol availability in C, C++

[Bruno Haible]

Albert Chin wrote on 2005-11-26:
> It's not necessarily safe to assume a system variable/function/header,
> if available to the C compiler, is available to the C++ compiler. This
> is even in the case the same vendor provides the C and C++ compiler.
> For example:
>   1. On Tru64 UNIX 5.1,  is available to the C compiler,
>  but not the C++ compiler.
>  $ cat test.c
> #include 
>  $ cc -c test.c
>  $ cp test.c test.cc
>  $ cxx -c test.cc
> cxx: Error: test.cc, line 1: could not open source file "stdint.h"
> #include 
> ---^
> cxx: Info: 1 error detected in the compilation of "test.cc".

Ouch. Then you will have to perform the autoconf test with the C++ compiler
instead of the C compiler. Use   AC_LANG_PUSH([C++])  before the test, and
AC_LANG_POP([C++])  after the test.

>   2. On HP-UX 11.23/IA,  will bring in mbstate_t for the
>  C++ compiler, but not the C89 compiler.
>  $ cat test.c
> #include 
>  $ cc -E test.c | grep mbstate_t

This is invalid, no? I have the following section in the INSTALL file
of GNU gettext:

---
Particular Systems
==

   On HP-UX, the default C compiler is not ANSI C compatible.  If GNU CC
is not installed, it is recommended to use the following options in order
to use an ANSI C compiler:

 env CC="cc -Ae" ./configure
---

> How do we solve this? We've currently solved it by implementing
> separate defines depending on the language. As an example, I've
> attached our patched mbstate_t.m4 below. We've done something similar
> for inttypes_h.m4, stdint_h.m4, and uintmax_t.m4. Is this the correct
> approach? Ideally, we should autodetect AC_PROG_CXX and build with the
> C++ compiler only if AC_PROG_CXX has been called (AC_PROVIDE_IFELSE?).

I'd suggest to use the stricter among the used language processors. In
this case it's probably C++ for most tests.

No need to change the .m4 files. Adding a pair of
   AC_LANG_PUSH([C++])
and
   AC_LANG_POP([C++])
in configure.ac should be enough.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: use of program_name

[Bruno Haible]

Karl Berry wrote on 2006-01-05:
> Is it a problem in practice, ie, what are these non-Unix linkers?

MacOS X (a Unix!), Woe32, emx+gcc (a Unix as well). Maybe others.

> Are you thinking that set_program_name will set something other than
> program_name?

It already does. See progname.c.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] use of program_name

[Bruno Haible]

Dave Love wrote on 2006-01-04:
> Gnulib routines call `error', and on a non-glibc system that's likely
> to use an uninitialized `program_name' since the variable is
> initialized in progname.c, and that's not required.  Users probably
> won't find out about it until `error' gets called at some stage and
> prints junk; ...

It is regrettable that newbie users of gnulib will get a core dump the
first time error() is called. But there's no way out except to document it,
because it is a consequence of
  - the fact that on Unix, you don't have access to argv[0] except from
within main(),
  - we _do_ want error messages to be generally prefixed by the program name.

> Shouldn't `program_name' be initialized in error.c instead (perhaps to
> a more meaningful value than NULL)?

If you do this, you spare the developer a one-time core dump and one line
of code. But the user will not know which programs prints a particular
error message. Which leads to decreased transparency of the system.
(I'm glad on Linux most error messages identify their originator.
Transparency is one of the major features of Linux compared to proprietary
OSes.)

> It could probably do with a note about this in gnulib.texi, but I
> don't know whether the variable is meant to be set directly or only
> through `set_program_name'.

Yes such a piece of doc is welcome. The advice is simple:

  - If the gnulib module 'progname' is in use,
 set_program_name (argv[0]);
should be called in main().

  - Otherwise the program should define program_name itself:

 const char *program_name;

and initialize it in main():

 program_name = argv[0];

> if gnulib supports a library, that can't ensure it's set anyway.

Using error() inside an exported, documented library is a bad idea anyway,
because error() can call exit(1), and most programs aren't prepared for
library calls that cause a program termination.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] sys/socket.h on mingw32 vs socklen (resend)

[Bruno Haible]

Simon Josefsson wrote on 2005-12-17:
> The sys_socket module below will create a sys/socket.h file, primarily
> for mingw32, but it could be extended for other systems or missing
> sys/socket.h features in the future.
> 
> This would solve the problem of accessing sys/socket.h stuff in
> applications.

I like this idea. So we can get rid of #if HAVE_SYS_SOCKET_H in many places.

> Index: lib/socket_.h
> ===
> RCS file: lib/socket_.h
> diff -N lib/socket_.h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ lib/socket_.h 16 Dec 2005 15:04:41 -
> @@ -0,0 +1,26 @@
> +/* Provide a sys/socket header file for systems lacking it (read: mingw32).
> +   Copyright (C) 2005 Free Software Foundation, Inc.
> +   Written by Simon Josefsson.
> +
> +   This program is free software; you can redistribute it and/or modify
> +   it under the terms of the GNU General Public License as published by
> +   the Free Software Foundation; either version 2, or (at your option)
> +   any later version.
> +
> +   This program is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +   GNU General Public License for more details.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with this program; if not, write to the Free Software Foundation,
> +   Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
> +
> +#ifndef _SYS_SOCKET_H
> +#define _SYS_SOCKET_H
> +
> +#if HAVE_WINSOCK2_H
> +# include 
> +#endif

Comments should indicate for which platforms this file is meant to be useful
and on which platforms you expect  to be present. (Currently only
mingw, I think?)

Also, this should include , so that socklen_t is defined
(and a type redefinition error is avoided when the user includes ).

> +
> +#endif /* _SYS_SOCKET_H */
> Index: m4/sys_socket_h.m4
> ===
> RCS file: m4/sys_socket_h.m4
> diff -N m4/sys_socket_h.m4
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ m4/sys_socket_h.m416 Dec 2005 15:04:41 -
> @@ -0,0 +1,19 @@
> +# sys_socket_h.m4 serial 1
> +dnl Copyright (C) 2005 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 From Simon Josefsson.
> +
> +AC_DEFUN([gl_HEADER_SYS_SOCKET],
> +[
> +  AC_CHECK_HEADERS_ONCE([sys/socket.h])
> +  if test $ac_cv_header_sys_socket_h = yes; then
> +SYS_SOCKET_H=''
> +  else
> +AC_CHECK_HEADERS_ONCE([winsock2.h])
> +SYS_SOCKET_H='sys/socket.h'
> +  fi
> +  AC_SUBST(SYS_SOCKET_H)
> +])

Looks good. Fine.

> Index: modules/sys_socket
> ===
> RCS file: modules/sys_socket
> diff -N modules/sys_socket
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ modules/sys_socket16 Dec 2005 15:04:41 -
> @@ -0,0 +1,36 @@
> +Description:
> +A  for systems lacking it.
> +(Currently only useful for mingw32, it will simply include winsock2.h.)
> +
> +Files:
> +lib/socket_.h
> +m4/sys_socket_h.m4
> +
> +Depends-on:
> +
> +configure.ac:
> +gl_HEADER_SYS_SOCKET
> +
> +Makefile.am:
> +BUILT_SOURCES += $(SYS_SOCKET_H)
> +EXTRA_DIST += socket_.h
> +
> +# We need the following in order to create  when the system
> +# doesn't have one that works with the given compiler.
> +sys/socket.h: socket_.h
> + mkdir sys

Create the directory only when it does not exist. (Otherwise the user is
blocked if he happens to press Ctrl-C after the sys directory has been
created but before sys/socket.h is present.)

> + cp $(srcdir)/socket_.h [EMAIL PROTECTED]
> + mv [EMAIL PROTECTED] $@
> +MOSTLYCLEANFILES += sys/socket.h sys/socket.h-t
> +
> +mostlylocal-clean:

Should be mostlyclean-local, not mostlylocal-clean.

> + rmdir sys

Remove the directory only when it exists and is empty. (Some systems create
files in your directories without being asked for, e.g. .DS_Store on MacOS X.)

> +
> +Include:
> +#include 
> +
> +License:
> +LGPL
> +
> +Maintainer:
> +Simon Josefsson

OK, good.

> However, it does not solve the problem of accessing sys/socket.h
> inside autoconf tests, and in particular from the socklen
> module.
> 
> Currently the socklen test fail on mingw32:
> 
> checking for socklen_t... no
> checking for socklen_t equivalent...
> configure: error: Cannot find a type to use in place of socklen_t
> 
> because:
> 
> configure:3814: i586-mingw32msvc-gcc -c -g -O2 conftest.c >&5
> conftest.c:23:26: sys/socket.h: No such file or directory
> 
> I can think of three solutions:
> 
> 0) In socklen, default the type to 'int' instead of aborting.  This
>would be compatible with mingw32, they use 'typedef int socklen_t'.
>

Re: [bug-gnulib] Re: use of program_name

[Bruno Haible]

Paul Eggert wrote on 2006-01-06:
> Perhaps we could change progname.h so that 'program_name' is a
> function that returns the program name, instead of being a global
> variable.

Ouch. When things go wrong, this leads to intriguing compiler errors like
"cannot call program_name as a function" or "assignment from function pointer
to data pointer". Or, in case of a mismatch between .o files, just core dumps.

And how would that function return the value of argv[0]? If it needs an
auxiliary '[const] char *' variable, you have not won much: you have pushed
the complexity back from gnulib into the developer's main program.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: Separate csharpcomp.sh, and a license problem

[Bruno Haible]

Simon Josefsson wrote on 2005-12-06:
> >> Shouldn't csharpcomp-script and javacomp-script also invoke
> >> AC_CONFIG_FILES on the scripts?  I need to do that manually now, and
> >> gnulib-tool didn't tell me about it.
> >>
> >> I can't come up with a simple patch -- the AC_CONFIG_FILES statement
> >> would have to include the directory somehow.
> >
> > You can probably assume that the .sh.in file is in the build-aux dir,
> > i.e. in $top_srcdir/$ac_aux_dir, and that the .sh file will be put into
> > the $top_builddir. Like for libtool for example. This should
> > simplify things.
> 
> This doesn't hold for csharpcomp.sh.in, does it?  It is in lib/.

I'm moving it to build-aux.

> >> Should we add another line in the modules-file, i.e.:
> >>
> >> Config-files:
> >> lib/csharpcomp.sh
> >
> > I don't think this is needed.
> 
> Generating the AC_CONFIG_FILES statements like a good thing.  How
> could that be achieved without a Config-files: statement?

A line in the 'configure.ac:' section is sufficient:
  AC_CONFIG_FILES([csharpcomp.sh:build-aux/csharpcomp.sh.in])

Bruno


2006-01-09  Bruno Haible  <[EMAIL PROTECTED]>

* build-aux/javacomp.sh.in: New file, moved from lib/.
* modules/javacomp-script (Files): Update.
(configure.ac): Add AC_CONFIG_FILES invocation.
(EXTRA_DIST): Remove variable.

* build-aux/javaexec.sh.in: New file, moved from lib/.
* modules/javaexec (Files): Update.
(configure.ac): Add AC_CONFIG_FILES invocation.
(EXTRA_DIST): Remove javaexec.sh.in.

* build-aux/csharpcomp.sh.in: New file, moved from lib/.
* modules/csharpcomp-script (Files): Update.
(configure.ac): Add AC_CONFIG_FILES invocation.
(EXTRA_DIST): Remove variable.

* build-aux/csharpexec.sh.in: New file, moved from lib/.
* modules/csharpexec (Files): Update.
(configure.ac): Add AC_CONFIG_FILES invocation.
(EXTRA_DIST): Remove csharpexec.sh.in.

diff -c -3 -r1.1 javacomp-script
*** modules/javacomp-script 2 Dec 2005 13:36:42 -   1.1
--- modules/javacomp-script 9 Jan 2006 13:43:07 -
***
*** 2,17 
  Script to compile a Java program.
  
  Files:
! lib/javacomp.sh.in
  m4/javacomp.m4
  
  Depends-on:
  
  configure.ac:
  gt_JAVACOMP
  
  Makefile.am:
- EXTRA_DIST += javacomp.sh.in
  
  License:
  GPLed build tool
--- 2,17 
  Script to compile a Java program.
  
  Files:
! build-aux/javacomp.sh.in
  m4/javacomp.m4
  
  Depends-on:
  
  configure.ac:
  gt_JAVACOMP
+ AC_CONFIG_FILES([javacomp.sh:build-aux/javacomp.sh.in])
  
  Makefile.am:
  
  License:
  GPLed build tool
diff -c -3 -r1.2 javaexec
*** modules/javaexec6 Jul 2005 15:58:47 -   1.2
--- modules/javaexec9 Jan 2006 13:43:07 -
***
*** 2,10 
  Execute a Java program.
  
  Files:
  lib/javaexec.h
  lib/javaexec.c
- lib/javaexec.sh.in
  m4/javaexec.m4
  
  Depends-on:
--- 2,10 
  Execute a Java program.
  
  Files:
+ build-aux/javaexec.sh.in
  lib/javaexec.h
  lib/javaexec.c
  m4/javaexec.m4
  
  Depends-on:
***
*** 21,31 
  
  configure.ac:
  gt_JAVAEXEC
  
  Makefile.am:
  DEFS += -DEXEEXT=\"$(EXEEXT)\"
  lib_SOURCES += javaexec.h javaexec.c
- EXTRA_DIST += javaexec.sh.in
  
  Include:
  "javaexec.h"
--- 21,31 
  
  configure.ac:
  gt_JAVAEXEC
+ AC_CONFIG_FILES([javaexec.sh:build-aux/javaexec.sh.in])
  
  Makefile.am:
  DEFS += -DEXEEXT=\"$(EXEEXT)\"
  lib_SOURCES += javaexec.h javaexec.c
  
  Include:
  "javaexec.h"
diff -c -3 -r1.1 csharpcomp-script
*** modules/csharpcomp-script   2 Dec 2005 13:36:59 -   1.1
--- modules/csharpcomp-script   9 Jan 2006 13:43:07 -
***
*** 2,8 
  Script to compile a C# program.
  
  Files:
! lib/csharpcomp.sh.in
  m4/csharpcomp.m4
  m4/csharp.m4
  
--- 2,8 
  Script to compile a C# program.
  
  Files:
! build-aux/csharpcomp.sh.in
  m4/csharpcomp.m4
  m4/csharp.m4
  
***
*** 10,18 
  
  configure.ac:
  gt_CSHARPCOMP
  
  Makefile.am:
- EXTRA_DIST += csharpcomp.sh.in
  
  License:
  GPLed build tool
--- 10,18 
  
  configure.ac:
  gt_CSHARPCOMP
+ AC_CONFIG_FILES([csharpcomp.sh:build-aux/csharpcomp.sh.in])
  
  Makefile.am:
  
  License:
  GPLed build tool
diff -c -3 -r1.4 csharpexec
*** modules/csharpexec  6 Jul 2005 15:58:47 -   1.4
--- modules/csharpexec  9 Jan 2006 13:43:07 -
***
*** 2,10 
  Execute a C# program.
  
  Files:
  lib/csharpexec.h
  lib/csharpexec.c
- lib/csharpexec.sh.in
  lib/classpath.h
  lib/classpath.c
  m4/csharpexec.m4
--- 2,10 
  Execute a C# program.
  
  Files:
+ build-aux/csharpexec.sh.in
  lib/csharpexec.h
  lib/csharpexec.c
  lib/classpath.h
  lib/classpath.c
  m4/csharpexec

Re: [bug-gnulib] Unconditionally call AC_PROG_RANLIB?

[Bruno Haible]

Simon Josefsson wrote on 2005-12-01:
> I'm setting this up in a separate directory.  Running autoconf
> on the gnulib generated stuff results in:
> 
> lib/Makefile.am:15: library used but `RANLIB' is undefined
> lib/Makefile.am:15:
> lib/Makefile.am:15: The usual way to define `RANLIB' is to add 
> `AC_PROG_RANLIB'
> lib/Makefile.am:15: to `configure.ac' and run `autoconf' again.
> 
> Should AC_PROG_RANLIB be called from gl_INIT?

Yes. From gl_INIT or gl_EARLY. I'm committing this patch, that makes
"gnulib-tool --import" more consistent with "gnulib-tool --create-testdir".

Bruno


2006-01-07  Bruno Haible  <[EMAIL PROTECTED]>

* gnulib-tool (func_import): Add an AC_PROG_RANLIB dependency to
gl_EARLY.

*** gnulib-tool.bak 2005-12-02 14:37:34.0 +0100
--- gnulib-tool 2006-01-07 16:41:09.0 +0100
***
*** 1,6 
  #! /bin/sh
  #
! # Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
  #
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
--- 1,6 
  #! /bin/sh
  #
! # Copyright (C) 2002-2006 Free Software Foundation, Inc.
  #
  # This program is free software; you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
***
*** 1242,1247 
--- 1242,1248 
  echo "# any checks for libraries, header files, types and library 
functions."
  echo "AC_DEFUN([${macro_prefix}_EARLY],"
  echo "["
+ echo "  AC_REQUIRE([AC_PROG_RANLIB])"
  if grep AC_GNU_SOURCE "$destdir"/$m4base/*.m4 > /dev/null; then
echo "  AC_REQUIRE([AC_GNU_SOURCE])"
  fi
***
*** 1255,1263 
  echo "AC_DEFUN([${macro_prefix}_INIT],"
  echo "["
  if test -z "$libtool"; then
!   echo "AM_CONDITIONAL([GL_COND_LIBTOOL], [false])"
  else
!   echo "AM_CONDITIONAL([GL_COND_LIBTOOL], [true])"
  fi
  for module in $modules; do
func_verify_module
--- 1256,1264 
  echo "AC_DEFUN([${macro_prefix}_INIT],"
  echo "["
  if test -z "$libtool"; then
!   echo "  AM_CONDITIONAL([GL_COND_LIBTOOL], [false])"
  else
!   echo "  AM_CONDITIONAL([GL_COND_LIBTOOL], [true])"
  fi
  for module in $modules; do
func_verify_module



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: use of program_name

[Bruno Haible]

Dave Love wrote on 2006-01-05:
> why can't it be initialized to null in error.c?

There are other modules using program_name than error.c. For example,
argmatch, argp-help and xerror. Consequently,
  - If you have an application that uses 'argp' but not 'error',
program_name would not be defined at all.
  - If you have an application that uses 'argp' and 'error',
program_name would be defined on non-glibc systems but lacking on
glibc systems (since on glibc systems, error.c is not compiled).

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: use of program_name

[Bruno Haible]

James Youngman wrote on 2006-01-05:
> My problem is that we have changed the interface without making it
> impossible for the user to use the new interface wrongly.  I would
> prefer an arrangement which results in a compilation or link failure
> if the user (i.e. software maintainer) fails to initialise things
> properly.  A runtime failure is insufficiently helpful in my opinion.

The appended patch will help against a direct assignment of program_name,
reminding the developer to call set_program_name().

Against a missing set_program_name call, we'll only have the core dump of
the error() function. Like now, against a missing program_name assignment.

> A runtime failure is insufficiently helpful in my opinion.

And how about a runtime failure that occurs in every invocation? We could
add a check in getopt() and getopt_long(), verifying that program_name is
non-NULL. Most GNU programs use getopt() and getopt_long().

Bruno


*** progname.h.bak  2005-05-14 15:46:42.0 +0200
--- progname.h  2006-01-07 03:10:40.0 +0100
***
*** 30,36 
  
  
  /* String containing name the program is called with.  */
! extern const char *program_name;
  
  /* Set program_name, based on argv[0].  */
  extern void set_program_name (const char *argv0);
--- 30,36 
  
  
  /* String containing name the program is called with.  */
! extern const char * const program_name;
  
  /* Set program_name, based on argv[0].  */
  extern void set_program_name (const char *argv0);
*** progname.c.bak  2005-09-21 13:08:21.0 +0200
--- progname.c  2006-01-07 03:10:22.0 +0100
***
*** 22,28 
--- 22,30 
  #endif
  
  /* Specification.  */
+ #define program_name readonly_program_name
  #include "progname.h"
+ #undef program_name
  
  #include 
  



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: use of program_name

[Bruno Haible]

Paul Eggert wrote on 2006-01-05:
> > (If the interface to it was just set_program_name, it could be private.)
> 
> Yes, that would be a better convention.  This will require revamping
> pretty much everybody that uses program_name, but I think it's worth
> the pain.  What do others think?

GNU gettext already uses set_program_name() instead of direct assignment to
program_name since 2001. The benefits are
  - The same call can be used for initializing the strings used by relocate()
[relocatable program installation].
  - Works around strange executable naming by libtool, when libtool is used
to link the program.

Both benefits are small enough by themselves, but show the typical reasons
why a functional interface is better than just a variable: Extensibility and
workarounds/hacks.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: stdint_.h vs intmax_t & uintmax_t

[Bruno Haible]

Paul Eggert wrote on 2005-11-15:
> I'd like Bruno's opinion on all this before installing into gnulib.
> 
> 2005-11-14  Paul Eggert  <[EMAIL PROTECTED]>
> 
>   * lib/stdint_.h (intmax_t) [defined intmax_t]: Do not declare.
>   (uintmax_t) [defined uintmax_t]: Do not declare.
>   (SIZE_MAX) [defined SIZE_MAX]: Do not define.
>   This works around a problem if intmax_t.m4 and/or uintmax_t.m4
>   and/or size_max.m4 are also used.  Problem reported by Mark D. Baushke.

Thanks for applying this patch while I was unavailable.

>  #ifdef _STDINT_H_HAVE_INT64
> +# ifndef intmax_t
>  typedef int64_t  intmax_t;
> +# endif
> +# ifndef uintmax_t
>  typedef uint64_t uintmax_t;
> +# endif

I'm worried that we arrive at a situation where
  sizeof (intmax_t) != sizeof (uintmax_t),
if the configure.ac has invoked gl_AC_TYPE_INTMAX_T but not gl_AC_TYPE_UINTMAX_T
or vice versa. I can see two solutions:
  a) Have gl_STDINT_H require gl_AC_TYPE_INTMAX_T and gl_AC_TYPE_UINTMAX_T.
  b) Merge gl_AC_TYPE_INTMAX_T and gl_AC_TYPE_UINTMAX_T into a single macro
 that defines intmax_t and uintmax_t simultaneously.
Which one is better?

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] argp: output formatting, and argp_child interface.

[Bruno Haible]

Paul Knowles wrote on 2005-12-15:
> *** Problem #1
> struct argp{
>   ...
>   /* A vector of argp_children structures, terminated by a member with a 0
>  argp field, pointing to child argps should be parsed with this one.  Any
>  conflicts are resolved in favor of this argp, or early argps in the
>  CHILDREN list.  This field is useful if you use libraries that supply
>  their own argp structure, which you want to use in conjunction with your
>  own.  */
>   __const struct argp_child *children;
>   ...
> }
> 
> In my opinion, much better would be 
> struct argp_child **children;
> for the reason that multiparser structures can then have an easy to
> use, scalable, interface.  By adding a function to add children, much
> of the complexity of the multiparser setup will go away.

Sorry, I don't understand. The argp facility is meant for a set of options
known when the program starts. (Otherwise how do you manage to write a
manual page for the program?) Do you mean to add options dynamically?

> *** Problem #2
> 
> Word wrapping should look at the COLUMNS environment variable to
> determine word wrap unless rmargin=N was explicitly set by the user in 
> ARGP_HELP_FMT.  It is silly that help text gets garbled and squashed
> up into 79 columns on my 110 column xterms and that the resizing is
> not automagic.

I agree. But you can get the desired behaviour yourself: Put the value
of getenv("COLUMNS") into ARGP_HELP_FMT. Roughly like this:

  const char *columns = getenv ("COLUMNS");
  if (columns != NULL && columns[0] != '\0')
{
  int icolumns = atoi (columns);
  if (icolumns >= 70) /* argp_help doesn't work well when there are too few 
columns */
{
  const char *old_fmt = getenv ("ARGP_HELP_FMT");
  char *new_fmt =
concatenate ("rmargin=", atoi (icolumns),
 old_fmt != NULL && old_fmt[0] != '\0'
 ? concatenate (",", old_fmt)
 : "");
  setenv ("ARGP_HELP_FMT", new_fmt, 1);
}
}

> ***  Problem 3;
>  I believe I have also stumbled on an output formatting problem, but
> the code to duplicate a test case of this is not yet ready.

Can you provide the test case, please?

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: stdint.h and Linux libc5

[Bruno Haible]

I committed this fix now.

> 2005-10-16  Bruno Haible  <[EMAIL PROTECTED]>
>
>   * m4/stdint.m4 (gl_STDINT_H): Also test for .
>   * lib/stdint_.h: On Linux libc4 and libc5, include 
>   and don't define _STDINT_H_NEED_SIGNED_INT_TYPES.



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: stdint_.h vs intmax_t & uintmax_t

[Bruno Haible]

Mark D. Baushke wrote on 2005-11-15:
> it would be more portable to use this:
> 
> #ifndef SIZE_MAX
> # define SIZE_MAX ((size_t)-1)
> #endif
> 
> because ((size_t)-1) will work even if size_t is narrower than int.

Yes. As explained on 2005-07-11, I prefer to write this as
  ((size_t)~(size_t)0)
because this way we don't need to refer to ISO C 99 6.3.1.3.(2).

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: sys/socket.h on mingw32 vs socklen (resend)

[Bruno Haible]

Simon Josefsson wrote:
> >> +  rmdir sys
> >
> > Remove the directory only when it exists and is empty. (Some systems
> > create files in your directories without being asked for, e.g. .DS_Store
> > on MacOS X.)
>
> How do I test for that in a portable way?

Let rmdir do the test, and ignore a possible error:

-rmdir sys 2>/dev/null

> Applications that need socklen_t should probably depend on
> the sys/socket.h module.  Perhaps the socklen_t module should depend
> on the sys_socket module?

I don't think so: Applications that use  but not 
are also supposed to be able to use socklen_t. See
http://www.opengroup.org/onlinepubs/009695399/basedefs/netdb.h.html

> Updated patch below.

Looks mostly good.

> +AC_DEFUN([gl_HEADER_SYS_SOCKET],
> +[
> +  AC_CHECK_HEADERS_ONCE([sys/socket.h])
> +  if test $ac_cv_header_sys_socket_h = yes; then
> +SYS_SOCKET_H=''
> +  else
> +AC_CHECK_HEADERS_ONCE([winsock2.h])

Here a test for ws2tcpip.h is missing.

> +SYS_SOCKET_H='sys/socket.h'
> +  fi
> +  AC_SUBST(SYS_SOCKET_H)
> +])

> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ modules/sys_socket9 Jan 2006 16:24:40 -
> @@ -0,0 +1,36 @@
> +Description:
> +A  for systems lacking it.
> +(Currently only useful for mingw32, it will simply include winsock2.h.)

The second line doesn't belong here, IMO, since it describes the
implementation of the module, which can change over time if we encounter
more bad systems.

Otherwise it looks fine, please commit!

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: Separate csharpcomp.sh, and a license problem

[Bruno Haible]

Simon Josefsson wrote:
> How would build-aux/ be substituted into $auxdir?  Should gnulib-tool
> substitute 'build-aux/' in configure.ac:-statements to $auxdir?

Yes, it should. I'll prepare a patch for doing this.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: inet_ntop fix for mingw32

[Bruno Haible]

Simon Josefsson wrote:
> > - sys/socket.h is currently included. It is not needed on OpenBSD 3.4.
> >   But it is needed for 'socklen_t' to be defined portably, I think - look
> >   at socklen.m4.
>
> Strictly, I don't believe it is needed -- arpa/inet.h must provide a
> prototype for inet_ntop and consequently also make sure socklen_t is
> available.

The "consequently" is a false deduction. Look how glibc does it is
numerous places: They define a private equivalent of the type - would
be __socklen_t here - and use this private equivalent in the function
prototypes. So you can have a prototype with a type identical to
socklen_t but socklen_t is nevertheless not visible.

> Hence, all code that use
> socklen_t will need to include that file, conditioned on
> HAVE_SYS_SOCKET_H.  Perhaps this:
>
> #ifdef HAVE_SYS_SOCKET_H
> # include 
> #endif
>
> should go into modules/socklen's Include statement then?

Yes, I agree. Similarly, I propose to modify modules/ssize as follows:

*** modules/ssize_t 15 Aug 2005 12:12:53 -  1.2
--- modules/ssize_t 9 Jan 2006 20:42:54 -
***
*** 12,17 
--- 12,18 
  Makefile.am:
  
  Include:
+ #include 
  
  License:
  unlimited


Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

strnlen include file

[Bruno Haible]

The module 'strnlen' has a strnlen.h include file. But it is not mentioned
in the module description. I'm committing this fix.

2006-01-09  Bruno Haible  <[EMAIL PROTECTED]>

* modules/strnlen (Include): Use strnlen.h.

*** modules/strnlen 11 Aug 2005 09:56:12 -  1.5
--- modules/strnlen 9 Jan 2006 21:39:51 -
***
*** 14,19 
--- 14,20 
  Makefile.am:
  
  Include:
+ "strnlen.h"
  
  License:
  LGPL



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] sysexits.h: Define EX_OK

[Bruno Haible]

Martin Lambers wrote:
> > But EX_OK is semantically the same as EXIT_SUCCESS. So what about this
> > patch?
>
> I think that the value 0 for EX_OK is obvious enough, so that the extra
> dependency on the exit module does not provide any real benefits.

OK, I've added EX_OK as 0 now. Sorry for the extremely long delay.

Bruno


2006-01-09  Bruno Haible  <[EMAIL PROTECTED]>

* sysexit_.h (EX_OK): New macro.
Suggested by Martin Lambers <[EMAIL PROTECTED]>.

*** lib/sysexit_.h  14 May 2005 06:03:58 -  1.2
--- lib/sysexit_.h  9 Jan 2006 21:47:32 -
***
*** 20,25 
--- 20,27 
  #ifndef _SYSEXITS_H
  #define _SYSEXITS_H
  
+ #define EX_OK 0 /* same value as EXIT_SUCCESS */
+ 
  #define EX_USAGE 64
  #define EX_DATAERR 65
  #define EX_NOINPUT 66



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: stdint_.h vs intmax_t & uintmax_t

[Bruno Haible]

Mark D. Baushke wrote:
> I have no problems with either
> ((size_t)~(size_t)0) or ((size_t)-1) being used.
> However, the previous definition in stdint_.h of
> '#define SIZE_MAX (~(size_t)0)' seemed wrong to me.

Yes, it was wrong. Thank you for noticing the problem.
I changed it to ((size_t)~(size_t)0) because I find it more comforting
to have no negative numbers involved when dealing with an unsigned type.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: use of -fno-common on Darwin

[Bruno Haible]

Paul Eggert wrote:
> "Peter O'Gorman" <[EMAIL PROTECTED]> writes:
> > getprogname(3), if it exists, can be used as well as other
> > alternatives (e.g. argv[0]).
>
> Thanks, I wasn't aware of the BSD getprogname until now.

Me too.

> How about this proposal?
>
> * Change the progname module to use the BSD getprogname naming
>   convention.  No sense reinventing the wheel.  That way, programs can
>   simply use the system-defined functions on BSD.
>
> * Rewrite the other gnulib code to use the new convention.
>
> * Ask gnulib users to switch to the new convention.

Yes, that's the most sensible thing to do. If there are no objections,
I will change the 'progname' module accordingly.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

bug in memcoll module

[Bruno Haible]

Hi Paul,

This commit

2002-12-31  Paul Eggert  <[EMAIL PROTECTED]>

* memcoll.m4 (gl_MEMCOLL): Require AC_FUNC_MEMCMP.

causes a gnulib-tool error:

$ ./gnulib-tool --create-testdir --dir=testdir memcoll
Module list with included dependencies:
  memcoll
File list:
  lib/memcoll.c
  lib/memcoll.h
  m4/memcoll.m4
  m4/onceonly_2_57.m4
executing autoreconf --force --install
configure.ac: installing `build-aux/install-sh'
configure.ac: installing `build-aux/missing'
lib/Makefile.am:17: required file `lib/memcmp.c' not found
autoreconf: automake failed with exit status: 1

Actually, memcoll.m4 should require gl_FUNC_MEMCMP, not AC_FUNC_MEMCMP,
since it is meant to use the memcmp.c replacement.

IMO, the fix depends whether you trust memcmp() these days.
If yes, then do not require AC_FUNC_MEMCMP.
If no, then make a dependency from 'memcoll' to 'memcmp'. And then you don't
   need to require AC_FUNC_MEMCMP either, since the gnulib-tool
   dependency mechanism will take care of invoking gl_FUNC_MEMCMP.

In either case, the appended patch should be part of the fix.

Bruno


*** m4/memcoll.m4.bak   2005-03-22 15:39:12.0 +0100
--- m4/memcoll.m4   2006-01-08 15:05:26.0 +0100
***
*** 1,5 
! # memcoll.m4 serial 5
! dnl Copyright (C) 2002, 2003, 2005 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.
--- 1,5 
! # memcoll.m4 serial 6
! dnl Copyright (C) 2002, 2003, 2005, 2006 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.
***
*** 10,15 
AC_LIBOBJ([memcoll])
  
dnl Prerequisites of lib/memcoll.c.
-   AC_REQUIRE([AC_FUNC_MEMCMP])
AC_FUNC_STRCOLL
  ])
--- 10,14 




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

bug in 'iconvme' module

[Bruno Haible]

Simon,

On MacOS X with GNU libiconv module, the iconvme module exhibits a build
failure:

Making all in lib
make  all-am
gcc -DHAVE_CONFIG_H -I. -I../../../megatestdir/iconvme/lib -I.. -g -O2 -c 
../../../megatestdir/iconvme/lib/iconvme.c
../../../megatestdir/iconvme/lib/iconvme.c: In function `iconv_alloc':
../../../megatestdir/iconvme/lib/iconvme.c:134: warning: passing arg 2 of 
`libiconv' from incompatible pointer type
rm -f libgnu.a
ar cru libgnu.a iconvme.o -liconv
ar: -liconv: No such file or directory
make[4]: *** [libgnu.a] Error 1
make[4]: Target `all-am' not remade because of errors.
make[3]: *** [all] Error 2

IMO you need to add $(LTLIBICONV) to lib_LDFLAGS, not lib_LIBADD.
And also, use $(LIBICONV) instead of $(LTLIBICONV) when libtool is not used.
That's why you introduced GL_COND_LIBTOOL conditional, no?

Bruno




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

use of autoreconf requires AM_GNU_GETTEXT_VERSION

[Bruno Haible]

Hi,

The use of autoreconf, introduced on 2004-09-18, causes
./gnulib-tool --create-testdir --dir=/dev/shm/testdir gettext
to fail:
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION

I'm committing this fix.


2006-01-07  Bruno Haible  <[EMAIL PROTECTED]>

* modules/gettext (configure.ac): Add an invocation of
AM_GNU_GETTEXT_VERSION. Needed since autoreconf is used by gnulib-tool.

*** modules/gettext.bak 2005-09-15 22:36:09.0 +0200
--- modules/gettext 2006-01-07 19:29:53.0 +0100
***
*** 36,41 
--- 36,42 
  
  configure.ac:
  AM_GNU_GETTEXT([external])
+ AM_GNU_GETTEXT_VERSION([0.14.5])
  
  Makefile.am:
  




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] localcharset needs HAVE_DECL_GETC_UNLOCKED

[Bruno Haible]

Werner LEMBERG wrote:
> The file localcharset.c asks for the preprocessor symbol
> HAVE_DECL_GETC_UNLOCKED which doesn't get defined in the m4 files
> listed in modules/localcharset.

I committed this fix:

2006-01-10  Bruno Haible  <[EMAIL PROTECTED]>

* localcharset.m4 (gl_LOCALCHARSET): Also test for getc_unlocked.
Reported by Werner Lemberg <[EMAIL PROTECTED]>.

*** localcharset.m4 18 Jan 2005 13:07:56 -  1.3
--- localcharset.m4 10 Jan 2006 13:55:33 -
***
*** 1,5 
! # localcharset.m4 serial 2
! dnl Copyright (C) 2002 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.
--- 1,5 
! # localcharset.m4 serial 3
! dnl Copyright (C) 2002, 2004, 2006 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.
***
*** 9,14 
--- 9,15 
dnl Prerequisites of lib/localcharset.c.
AC_CHECK_HEADERS_ONCE(stddef.h stdlib.h string.h)
AC_REQUIRE([AM_LANGINFO_CODESET])
+   AC_CHECK_DECLS_ONCE(getc_unlocked)
AC_CHECK_FUNCS_ONCE(setlocale)
  
dnl Prerequisites of the lib/Makefile.am snippet.



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] another warning in localcharset.c

[Bruno Haible]

Werner Lemberg wrote:
> During compilation with gcc 3.3.3 I get
>
>   localcharset.c:110: warning: function declaration isn't a prototype

OK, should now be fixed in gnulib CVS:


2006-01-10  Bruno Haible  <[EMAIL PROTECTED]>

  * localcharset.c: Update from GNU gettext.

*** localcharset.c  14 May 2005 06:03:58 -  1.20
--- localcharset.c  10 Jan 2006 13:49:31 -
***
*** 1,6 
  /* Determine a canonical name for the current locale's character encoding.
  
!Copyright (C) 2000-2004 Free Software Foundation, Inc.
  
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
--- 1,6 
  /* Determine a canonical name for the current locale's character encoding.
  
!Copyright (C) 2000-2006 Free Software Foundation, Inc.
  
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
***
*** 106,112 
  
  /* Return a pointer to the contents of the charset.alias file.  */
  static const char *
! get_charset_aliases ()
  {
const char *cp;
  
--- 106,112 
  
  /* Return a pointer to the contents of the charset.alias file.  */
  static const char *
! get_charset_aliases (void)
  {
const char *cp;
  
***
*** 248,253 
--- 248,254 
   "CP1361" "\0" "JOHAB" "\0"
   "CP20127" "\0" "ASCII" "\0"
   "CP20866" "\0" "KOI8-R" "\0"
+  "CP20936" "\0" "GB2312" "\0"
   "CP21866" "\0" "KOI8-RU" "\0"
   "CP28591" "\0" "ISO-8859-1" "\0"
   "CP28592" "\0" "ISO-8859-2" "\0"
***
*** 258,264 
   "CP28597" "\0" "ISO-8859-7" "\0"
   "CP28598" "\0" "ISO-8859-8" "\0"
   "CP28599" "\0" "ISO-8859-9" "\0"
!  "CP28605" "\0" "ISO-8859-15" "\0";
  # endif
  #endif
  
--- 259,272 
   "CP28597" "\0" "ISO-8859-7" "\0"
   "CP28598" "\0" "ISO-8859-8" "\0"
   "CP28599" "\0" "ISO-8859-9" "\0"
!  "CP28605" "\0" "ISO-8859-15" "\0"
!  "CP38598" "\0" "ISO-8859-8" "\0"
!  "CP51932" "\0" "EUC-JP" "\0"
!  "CP51936" "\0" "GB2312" "\0"
!  "CP51949" "\0" "EUC-KR" "\0"
!  "CP51950" "\0" "EUC-TW" "\0"
!  "CP54936" "\0" "GB18030" "\0"
!  "CP65001" "\0" "UTF-8" "\0";
  # endif
  #endif
  
***
*** 278,284 
  STATIC
  #endif
  const char *
! locale_charset ()
  {
const char *codeset;
const char *aliases;
--- 286,292 
  STATIC
  #endif
  const char *
! locale_charset (void)
  {
const char *codeset;
const char *aliases;



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

work around automake error

[Bruno Haible]

Hi,

./gnulib-tool --create-testdir --dir=/dev/shm/testdir --with-tests gettext
gives an error:
configure.ac: AM_GNU_GETTEXT used but SUBDIRS not defined
autoreconf: automake failed with exit status: 1

I'm committing this fix.

2006-01-07  Bruno Haible  <[EMAIL PROTECTED]>

* gnulib-tool (func_emit_tests_Makefile_am): Emit an empty SUBDIR
variable.
Needed to avoid an automake error regarding the 'gettext' module.

*** gnulib-tool.bak 2006-01-07 16:41:09.0 +0100
--- gnulib-tool 2006-01-07 19:41:07.0 +0100
***
*** 748,753 
--- 748,757 
echo
echo "ACLOCAL_AMFLAGS = -I ${testsbase_inverse}/${m4base}"
echo
+   # Nothing is being added to SUBDIRS; nevertheless the existence of this
+   # variable is needed to avoid an error from automake:
+   #   "AM_GNU_GETTEXT used but SUBDIRS not defined"
+   echo "SUBDIRS ="
echo "TESTS ="
echo "TESTS_ENVIRONMENT ="
echo "noinst_PROGRAMS ="




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

__const

[Bruno Haible]

Hi,

I think it's time to get rid of __const. gnulib assumes an ANSI C compiler,
glibc does as well. The following glibc public header files already assume
an ANSI C compiler that groks 'const':

/usr/include/argp.h
/usr/include/assert.h
/usr/include/error.h
/usr/include/fstab.h
/usr/include/fts.h
/usr/include/gconv.h
/usr/include/getopt.h
/usr/include/libio.h
/usr/include/link.h
/usr/include/netdb.h
/usr/include/obstack.h
/usr/include/regex.h
/usr/include/regexp.h
/usr/include/resolv.h
/usr/include/spawn.h
/usr/include/thread_db.h
/usr/include/xlocale.h

Therefore I propose this patch.

2006-01-07  Bruno Haible  <[EMAIL PROTECTED]>

* argp.h (__const): Remove macro. Use const instead.
* argp-fmtstream.h (__const): Likewise.
* glob_.h (__const): Remove macro.
* glob-libc.h: Use const instead of __const.

*** argp.h.bak  2005-07-04 13:16:19.0 +0200
--- argp.h  2006-01-07 18:33:51.0 +0100
***
*** 1,5 
  /* Hierarchial argument parsing, layered over getopt.
!Copyright (C) 1995-1999,2003,2004 Free Software Foundation, Inc.
 This file is part of the GNU C Library.
 Written by Miles Bader <[EMAIL PROTECTED]>.
  
--- 1,5 
  /* Hierarchial argument parsing, layered over getopt.
!Copyright (C) 1995-1999,2003-2006 Free Software Foundation, Inc.
 This file is part of the GNU C Library.
 Written by Miles Bader <[EMAIL PROTECTED]>.
  
***
*** 28,37 
  #define __need_error_t
  #include 
  
- #ifndef __const
- # define __const const
- #endif
- 
  #ifndef __THROW
  # define __THROW
  #endif
--- 28,33 
***
*** 82,88 
  {
/* The long option name.  For more than one name for the same option, you
   can use following options with the OPTION_ALIAS flag set.  */
!   __const char *name;
  
/* What key is returned for this option.  If > 0 and printable, then it's
   also accepted as a short option.  */
--- 78,84 
  {
/* The long option name.  For more than one name for the same option, you
   can use following options with the OPTION_ALIAS flag set.  */
!   const char *name;
  
/* What key is returned for this option.  If > 0 and printable, then it's
   also accepted as a short option.  */
***
*** 90,96 
  
/* If non-NULL, this is the name of the argument associated with this
   option, which is required unless the OPTION_ARG_OPTIONAL flag is set. */
!   __const char *arg;
  
/* OPTION_ flags.  */
int flags;
--- 86,92 
  
/* If non-NULL, this is the name of the argument associated with this
   option, which is required unless the OPTION_ARG_OPTIONAL flag is set. */
!   const char *arg;
  
/* OPTION_ flags.  */
int flags;
***
*** 99,105 
   will be printed outdented from the normal option column, making it
   useful as a group header (it will be the first thing printed in its
   group); in this usage, it's conventional to end the string with a `:'.  
*/
!   __const char *doc;
  
/* The group this option is in.  In a long help message, options are sorted
   alphabetically within each group, and the groups presented in the order
--- 95,101 
   will be printed outdented from the normal option column, making it
   useful as a group header (it will be the first thing printed in its
   group); in this usage, it's conventional to end the string with a `:'.  
*/
!   const char *doc;
  
/* The group this option is in.  In a long help message, options are sorted
   alphabetically within each group, and the groups presented in the order
***
*** 227,233 
  {
/* An array of argp_option structures, terminated by an entry with both
   NAME and KEY having a value of 0.  */
!   __const struct argp_option *options;
  
/* What to do with an option from this structure.  KEY is the key
   associated with the option, and ARG is any associated argument (NULL if
--- 223,229 
  {
/* An array of argp_option structures, terminated by an entry with both
   NAME and KEY having a value of 0.  */
!   const struct argp_option *options;
  
/* What to do with an option from this structure.  KEY is the key
   associated with the option, and ARG is any associated argument (NULL if
***
*** 243,254 
   contains newlines, the strings separated by them are considered
   alternative usage patterns, and printed on separate lines (lines after
   the first are prefix by `  or: ' instead of `Usage:').  */
!   __const char *args_doc;
  
/* If non-NULL, a string containing extra text to be printed before and
   after the options in a long help message (separated by a vertical tab
   `\v' character).  */
!   __const char *doc;
  
/* A vector of argp_children structures, terminated by a member with a 0
   

bug in strtok_r module

[Bruno Haible]

$ ./gnulib-tool --create-testdir --dir=testdir strtok_r
...
configure.ac:14: warning: gl_C_RESTRICT is m4_require'd but is not m4_defun'd
configure.ac:14: gl_C_RESTRICT is required by...
m4/strtok_r.m4:17: gl_PREREQ_STRTOK_R is expanded from...
m4/strtok_r.m4:12: gl_FUNC_STRTOK_R is expanded from...

The reason is that m4/strtok_r.m4 invokes gl_C_RESTRICT, but m4/restrict.m4 is
not part of this module or its dependencies.

Here is a fix. OK to commit?


2006-01-08  Bruno Haible  <[EMAIL PROTECTED]>

* modules/strtok_r: Depend on module restrict.

*** modules/strtok_r.bak2004-11-12 01:00:47.0 +0100
--- modules/strtok_r2006-01-08 16:30:45.0 +0100
***
*** 7,12 
--- 7,13 
  m4/strtok_r.m4
  
  Depends-on:
+ restrict
  
  configure.ac:
  gl_FUNC_STRTOK_R




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

bug in readutmp module

[Bruno Haible]

Jim,

"gnulib-tool --create-megatestdir --dir=/dev/shm/testdir --with-tests"
shows this:

configure.ac:20: warning: gl_FUNC_FREE is m4_require'd but is not m4_defun'd
configure.ac:20: gl_FUNC_FREE is required by...
m4/readutmp.m4:55: gl_READUTMP is expanded from...

The reason is that m4/readutmp.m4 invokes gl_FUNC_FREE, but m4/free.m4 is not
part of this module or its dependencies.

Here is a fix. OK to commit?


2006-01-08  Bruno Haible  <[EMAIL PROTECTED]>

* m4/readutmp.m4 (gl_READUTMP): Don't require gl_FUNC_FREE. Use a
module dependency instead.
* modules/readutmp: Depend on module free.

*** m4/readutmp.m4.bak  2005-05-02 13:27:38.0 +0200
--- m4/readutmp.m4  2006-01-08 15:30:53.0 +0100
***
*** 1,5 
! # readutmp.m4 serial 9
! dnl Copyright (C) 2002, 2003, 2004, 2005 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.
--- 1,5 
! # readutmp.m4 serial 10
! dnl Copyright (C) 2002, 2003, 2004, 2005, 2006 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.
***
*** 11,17 
  
dnl Prerequisites of lib/readutmp.h and lib/readutmp.c.
AC_REQUIRE([AC_C_INLINE])
-   AC_REQUIRE([gl_FUNC_FREE])
AC_CHECK_HEADERS_ONCE(utmp.h utmpx.h)
AC_CHECK_FUNCS_ONCE(utmpname utmpxname)
AC_CHECK_DECLS(getutent,,,[
--- 11,16 
*** modules/readutmp.bak2005-05-09 16:27:12.0 +0200
--- modules/readutmp2006-01-08 15:31:09.0 +0100
***
*** 8,13 
--- 8,14 
  
  Depends-on:
  xalloc
+ free
  stdbool
  
  configure.ac:




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: getprogname

[Bruno Haible]

Peter O'Gorman wrote:
> Solaris seems to have a getexecname

Interesting. So this provides a fallback, like on glibc systems, for the
case when setprogname(argv[0]) has not been called.

> I'd suggest the following instead of Paul's proposal, as it allows
> the programmer to override the program name.

Well, Paul's proposal to use 'get/setprogname' also allows the
programmer to override the program name.

> static char * prog_name = NULL;
>
> void
> set_prog_name(char * name)
> {
>   if (prog_name) free(prog_name);
>   prog_name = strdup(name);
> }
>
> char *
> get_prog_name(void)
> {
>   char * name;
>   if (prog_name)
>   name = prog_name;
>   else
>   {
> #if defined(HAVE_GETPROGNAME)
> #include 
>   name = getprogname();
> #elif defined(HAVE_GETEXECNAME)
> #include 
>   name = getexecname();
> #elif defined(HAVE_PROGRAM_INVOCATION_SHORT_NAME)
> #include 
>   name = program_invocation_short_name;
> #else
>   name = "executable";
> #endif
>   }
>   return name;
> }

Well, my intention is basically this:

#if !(HAVE_GETPROGNAME && HAVE_SETPROGNAME) /* nothing to do on FreeBSD, NetBSD 
*/

static const char * progname = NULL;

void
setprogname(const char *arg)
{
  progname = arg;
}

const char *
getprogname()
{
  if (progname != NULL)
/* actually not only basename, but also remove leading "-" and ".lt-" */
return basename (progname);
  else
{
  #if HAVE_PROGRAM_INVOCATION_SHORT_NAME /* glibc */
return program_invocation_short_name;
  #elif HAVE_GETEXECNAME /* Solaris */
return basename (getexecname ());
  #else
return NULL;
  #endif
}
}

#endif

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: bug in readutmp module

[Bruno Haible]

Jim Meyering wrote:
> However, I'm reluctant to remove the AC_REQUIRE, since
> that would make the code+.m4 combination depend silently on
> having a particular implementation of free.

Yes, I understand. By looking at the source code, it's not immediately
clear which free() variant is meant.

> Thinking about it some more, it seems backwards to move the
> dependency information from the .m4 file to the module file.
> I think of the .m4 file as recording dependencies inherent in the
> corresponding source files.

The benefit of the module dependency is that it is immune against changes
in the interface of the other module. For example, when you rename
jm_SSIZE_T to gl_TYPE_SSIZE_T, or add other lines in the "configure.ac"
section of the module, the higher-level module doesn't need to be changed.

The drawback is obviously that if you have several source files gathered
in a module, you lose track which file needs what, if you don't have a
more fine-grained way of tracking the dependency. You could choose to
track them through comments. Or in the .m4 file. Either is fine with me.

> How about if we leave the now-redundant
> AC_REQUIRE in place for now?

Done. I committed only the other part.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: getprogname

[Bruno Haible]

Paul Eggert wrote:
> This isn't as compatible as possible with BSD, as BSD setprogname
> ignores its argument when the true program name is available from
> the operating system.

Huh? My reading of the sources of FreeBSD

  
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/getprogname.c?rev=1.4&content-type=text/x-cvsweb-markup
  
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/setprogname.c?rev=1.8&content-type=text/x-cvsweb-markup

and NetBSD

  
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/gen/getprogname.c?rev=1.3&content-type=text/x-cvsweb-markup
  
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/gen/setprogname.c?rev=1.3&content-type=text/x-cvsweb-markup

is just the opposite: Whatever may the initial value of __progname be,
it is erased when setprogname is called.

Which is also reasonable: you want to allow an application to override
system behaviour, not the other way around.

> LibGW32C-0.3 has getexecname (see
> ), so
> that function is not unique to Solaris.

And LibGW32C-0.4 (see http://gnuwin32.sourceforge.net/packages/libgw32c.htm)
has apparently renamed this function to getprogname(). While _not_ providing
a setprogname().

> Surely you meant base_name rather than basename?

What I presented was only a sketch. Let's discuss details when I show
the real code.

> How about something like this instead?

It's missing the removal of the dirname, of "-" and of "lt-". Also,
it lacks a setprogname() function if the system provides getprogname()
but not setprogname().

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] no module for progreloc

[Bruno Haible]

Werner LEMBERG wrote:
> There isn't a file `modules/progreloc' which looks like a bug to me
> since it depends on progname.

Yes, the "relocatable" stuff does not yet fit into a gnulib module.
The installation instructions ([1]) require some modification to
every Makefile.am and to every installable executable or shell script.
I believe it will need a bit of automake support in order to work as
transparently as other features.

Bruno

[1] http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

avoiding "ar: no archive members specified" error on MacOS X

[Bruno Haible]

This patch makes gnulib-tool generated packages work on MacOS X, even when
no object files is needed in the library. We already have a 'dummy' module
for this case. Now gnulib-tool makes use of it.

2006-01-08  Bruno Haible  <[EMAIL PROTECTED]>

Avoid "ar: no archive members specified" error on MacOS X.
* gnulib-tool (func_modules_add_dummy): New function.
(func_import, func_create_testdir): Invoke it.





*** gnulib-tool.bak	2006-01-08 16:43:14.0 +0100
--- gnulib-tool	2006-01-08 22:09:24.0 +0100
***
*** 634,639 
--- 634,673 
done
  }
  
+ # func_modules_add_dummy
+ # Input:
+ # - modules list of modules, including dependencies
+ # Output:
+ # - modules list of modules, including 'dummy' if needed
+ func_modules_add_dummy ()
+ {
+   have_lib_SOURCES=
+   sed_remove_backslash_newline=':a
+ /\\$/{
+ s/\\$//
+ N
+ s/\n//
+ ba
+ }'
+   for module in $modules; do
+ func_verify_nontests_module
+ if test -n "$module"; then
+   # Extract the value of "lib_SOURCES += ...".
+   for file in `func_get_automake_snippet "$module" | sed -e "$sed_remove_backslash_newline" | sed -n -e 's,^lib_SOURCES[ 	]*+=\([^#]*\).*$,\1,p'`; do
+ # Ignore .h files since they are not compiled.
+ case "$file" in
+   *.h) ;;
+   *) have_lib_SOURCES=yes ;;
+ esac
+   done
+ fi
+   done
+   # Add the dummy module, to make sure the library will be non-empty.
+   if test -z "$have_lib_SOURCES"; then
+ modules="$modules dummy"
+   fi
+ }
+ 
  # func_modules_to_filelist
  # Input:
  # - modules list of modules, including dependencies
***
*** 945,950 
--- 979,987 
echo "Module list with included dependencies:"
echo "$modules" | sed -e 's/^/  /'
  
+   # Add the dummy module if needed.
+   func_modules_add_dummy
+ 
# If --lgpl, check the license of modules are compatible.
if test -n "$lgpl"; then
  for module in $modules; do
***
*** 1390,1395 
--- 1427,1435 
echo "Module list with included dependencies:"
echo "$modules" | sed -e 's/^/  /'
  
+   # Add the dummy module if needed.
+   func_modules_add_dummy
+ 
# Determine final file list.
func_modules_to_filelist
echo "File list:"
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

gl_LOCK vs. gl_ARGP ordering

[Bruno Haible]

$ ./gnulib-tool --create-testdir --dir=testdir argp lock
...
configure.ac:36: warning: gl_ARGP was called before gl_LOCK
m4/lock.m4:224: gl_LOCK is expanded from...

I'm committing this fix.

2006-01-08  Bruno Haible  <[EMAIL PROTECTED]>

Ensure automatic ordering between gl_LOCK and gl_ARGP.
* gnulib-tool (func_import, func_create_testdir): Put gl_LOCK into
the "early" section as well.
* lock.m4 (gl_LOCK_BODY): Renamed from gl_LOCK.
(gl_LOCK): New macro, requiring gl_LOCK_BODY.

*** gnulib-tool.bak 2006-01-08 16:23:19.0 +0100
--- gnulib-tool 2006-01-08 16:43:14.0 +0100
***
*** 13,20 
  # GNU General Public License for more details.
  #
  # You should have received a copy of the GNU General Public License
! # along with this program; if not, write to the Free Software
! # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 
USA.
  #
  
  # This program is meant for authors or maintainers which want to import
--- 13,20 
  # GNU General Public License for more details.
  #
  # You should have received a copy of the GNU General Public License
! # along with this program; if not, write to the Free Software Foundation,
! # Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
  #
  
  # This program is meant for authors or maintainers which want to import
***
*** 1261,1266 
--- 1261,1269 
  if grep gl_USE_SYSTEM_EXTENSIONS "$destdir"/$m4base/*.m4 > /dev/null; then
echo "  AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])"
  fi
+ if grep gl_LOCK "$destdir"/$m4base/*.m4 > /dev/null; then
+   echo "  AC_REQUIRE([gl_LOCK])"
+ fi
  echo "])"
  echo
  echo "# This macro should be invoked from $configure_ac, in the section"
***
*** 1472,1477 
--- 1475,1484 
 echo "gl_USE_SYSTEM_EXTENSIONS"
 echo
   fi
+  if grep gl_LOCK "$testdir"/m4/*.m4 > /dev/null; then
+echo "gl_LOCK"
+echo
+  fi
   if test -z "$libtool"; then
 echo "AM_CONDITIONAL([GL_COND_LIBTOOL], [false])"
   else
***
*** 1536,1541 
--- 1543,1552 
   echo "gl_USE_SYSTEM_EXTENSIONS"
   echo
 fi
+if grep gl_LOCK "$testdir"/m4/*.m4 > /dev/null; then
+  echo "gl_LOCK"
+  echo
+fi
 if test -z "$libtool"; then
   echo "AM_CONDITIONAL([GL_COND_LIBTOOL], [false])"
 else
*** m4/lock.m4.bak  2005-07-26 14:43:35.0 +0200
--- m4/lock.m4  2006-01-08 16:47:37.0 +0100
***
*** 1,4 
! # lock.m4 serial 1 (gettext-0.15)
  dnl Copyright (C) 2005 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
--- 1,4 
! # lock.m4 serial 2 (gettext-0.15)
  dnl Copyright (C) 2005 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
***
*** 21,26 
--- 21,33 
  
  AC_DEFUN([gl_LOCK],
  [
+   AC_REQUIRE([gl_LOCK_BODY])
+ ])
+ 
+ dnl The guts of gl_LOCK. Needs to be expanded only once.
+ 
+ AC_DEFUN([gl_LOCK_BODY],
+ [
dnl Ordering constraints: This macro modifies CPPFLAGS in a way that
dnl influences the result of the autoconf tests that test for *_unlocked
dnl declarations, on AIX 5 at least. Therefore it must come early.




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

warnings in 'argp' module

[Bruno Haible]

The argp module has warnings on Linux/glibc:

gcc -DHAVE_CONFIG_H -I. -I/packages/megatestdir/argp/lib -I.. -g -O2 -c 
/packages/megatestdir/argp/lib/argp-parse.c
/packages/megatestdir/argp/lib/argp-parse.c: In function `argp_default_parser':
/packages/megatestdir/argp/lib/argp-parse.c:112: warning: assignment makes 
pointer from integer without a cast
/packages/megatestdir/argp/lib/argp-parse.c: In function `parser_init':
/packages/megatestdir/argp/lib/argp-parse.c:561: warning: assignment makes 
pointer from integer without a cast

Bruno




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

warnings in 'filenamecat' module

[Bruno Haible]

The 'filenamecat' module has warnings on Linux/glibc:

gcc -DHAVE_CONFIG_H -I. -I/packages/megatestdir/filenamecat/lib -I.. -g -O2 
-c /packages/megatestdir/filenamecat/lib/filenamecat.c
/packages/megatestdir/filenamecat/lib/filenamecat.c: In function 
`file_name_concat':
/packages/megatestdir/filenamecat/lib/filenamecat.c:78: warning: assignment 
makes pointer from integer without a cast
/packages/megatestdir/filenamecat/lib/filenamecat.c:85: warning: assignment 
makes pointer from integer without a cast

IMO modules/filenamecat should depend on 'mempcpy', and
lib/filenamecat.c should #include "mempcpy.h".

Bruno




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: Separate csharpcomp.sh, and a license problem

[Bruno Haible]

Simon Josefsson wrote:
> How would build-aux/ be substituted into $auxdir?  Should gnulib-tool
> substitute 'build-aux/' in configure.ac:-statements to $auxdir?

I committed this patch.

2006-01-11  Bruno Haible  <[EMAIL PROTECTED]>

* gnulib-tool (func_import, func_create_testdir): Replace build-aux
with $auxdir in AC_CONFIG_FILES statements.

*** gnulib-tool 10 Jan 2006 13:37:12 -  1.94
--- gnulib-tool 11 Jan 2006 12:22:41 -
***
*** 1264,1273 
  else
echo "  AM_CONDITIONAL([GL_COND_LIBTOOL], [true])"
  fi
  for module in $modules; do
func_verify_module
if test -n "$module"; then
! func_get_autoconf_snippet "$module" | sed -e '/^$/d;' -e 's/^/  /' -e 
's/AM_GNU_GETTEXT(\[external\])/dnl you must add AM_GNU_GETTEXT([external]) or 
similar to configure.ac./'
  if test "$module" = 'alloca' && test -n "$libtool"; then
echo 'changequote(,)dnl'
echo 'LTALLOCA=`echo "$ALLOCA" | sed '"'"'s/\.[^.]* /.lo 
/g;s/\.[^.]*$/.lo/'"'"'`'
--- 1264,1283 
  else
echo "  AM_CONDITIONAL([GL_COND_LIBTOOL], [true])"
  fi
+ sed_replace_build_aux='
+   :a
+   /AC_CONFIG_FILES(.*:build-aux\/.*)/{
+ 
s|AC_CONFIG_FILES(\(.*\):build-aux/\(.*\))|AC_CONFIG_FILES(\1:'"$auxdir"'/\2)|
+ ba
+   }'
+ sed_replace_build_aux=`echo "$sed_replace_build_aux" | sed -e 1d -e 's/^ 
*//'`
  for module in $modules; do
func_verify_module
if test -n "$module"; then
! func_get_autoconf_snippet "$module" \
!   | sed -e '/^$/d;' -e 's/^/  /' \
! -e 's/AM_GNU_GETTEXT(\[external\])/dnl you must add 
AM_GNU_GETTEXT([external]) or similar to configure.ac./' \
! -e "$sed_replace_build_aux"
  if test "$module" = 'alloca' && test -n "$libtool"; then
echo 'changequote(,)dnl'
echo 'LTALLOCA=`echo "$ALLOCA" | sed '"'"'s/\.[^.]* /.lo 
/g;s/\.[^.]*$/.lo/'"'"'`'
***
*** 1469,1487 
   else
 echo "AM_CONDITIONAL([GL_COND_LIBTOOL], [true])"
   fi
   # We don't have explicit ordering constraints between the various
   # autoconf snippets. It's cleanest to put those of the library before
   # those of the tests.
   for module in $modules; do
 func_verify_nontests_module
 if test -n "$module"; then
!  func_get_autoconf_snippet "$module"
 fi
   done
   for module in $modules; do
 func_verify_tests_module
 if test -n "$module"; then
!  func_get_autoconf_snippet "$module"
 fi
   done
   echo
--- 1479,1506 
   else
 echo "AM_CONDITIONAL([GL_COND_LIBTOOL], [true])"
   fi
+  sed_replace_build_aux='
+:a
+/AC_CONFIG_FILES(.*:build-aux\/.*)/{
+  
s|AC_CONFIG_FILES(\(.*\):build-aux/\(.*\))|AC_CONFIG_FILES(\1:../'"$auxdir"'/\2)|
+  ba
+}'
+  sed_replace_build_aux=`echo "$sed_replace_build_aux" | sed -e 1d -e 's/^ 
*//'`
   # We don't have explicit ordering constraints between the various
   # autoconf snippets. It's cleanest to put those of the library before
   # those of the tests.
   for module in $modules; do
 func_verify_nontests_module
 if test -n "$module"; then
!  func_get_autoconf_snippet "$module" \
!| sed -e "$sed_replace_build_aux"
 fi
   done
   for module in $modules; do
 func_verify_tests_module
 if test -n "$module"; then
!  func_get_autoconf_snippet "$module" \
!| sed -e "$sed_replace_build_aux"
 fi
   done
   echo
***
*** 1533,1542 
 else
   echo "AM_CONDITIONAL([GL_COND_LIBTOOL], [true])"
 fi
 for module in $modules; do
   func_verify_nontests_module
   if test -n "$module"; then
!func_get_autoconf_snippet "$module"
   fi
 done
 echo
--- 1552,1569 
 else
   echo "AM_CONDITIONAL([GL_COND_LIBTOOL], [true])"
 fi
+sed_replace_build_aux='
+  :a
+  /AC_CONFIG_FILES(.*:build-aux\/.*)/{
+
s|AC_CONFIG_FILES(\(.*\):build-aux/\(.*\))|AC_CONFIG_FILES(\1:'"$auxdir"'/\2)|
+ba
+  }'
+sed_replace_build_aux=`echo "$sed_replace_build_aux" | sed -e 1d -e 's/^ 
*//'`
 for module in $modules; do
   func_verify_nontests_module
   if test -n "$module"; then
!func_get_autoconf_snippet "$module" \
!  | sed -e "$sed_replace_build_aux"
   fi
 done
 echo



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

autoreconf is recursive

[Bruno Haible]

Hi Simon and Paul,

The func_create_megatestdir part of this patch

2004-09-18  Simon Josefsson  <[EMAIL PROTECTED]>
and  Paul Eggert  <[EMAIL PROTECTED]>

* gnulib-tool: Replace various ad-hoc automake/autoconf/aclocal
calls with autoreconf.  Define GL_LIB.

has the effect of nearly doubling the executing time of
"gnulib-tool --create-megatestdir --dir=/dev/shm/testdir".
4 hours vs. ca. 7 or 8 hours of CPU time - it matters. I'm reverting to
simple autoconf and automake calls for the toplevel directory.


2006-01-08  Bruno Haible  <[EMAIL PROTECTED]>

* gnulib-tool (AUTOMAKEPATH, AUTOCONF, ACLOCAL, AUTOMAKE): New
variables.
(func_create_megatestdir): Call aclocal, autoconf, automake here, not
autoreconf.

*** gnulib-tool.bak 2006-01-07 19:41:07.0 +0100
--- gnulib-tool 2006-01-08 13:30:35.0 +0100
***
*** 35,40 
--- 35,46 
  #;;
  #esac
  
+ # You can set AUTOMAKEPATH to empty if automake 1.9.x is already in your PATH.
+ AUTOMAKEPATH=
+ 
+ AUTOCONF="${AUTOCONFPATH}autoconf"
+ ACLOCAL="${AUTOMAKEPATH}aclocal"
+ AUTOMAKE="${AUTOMAKEPATH}automake"
  AUTORECONF="${AUTOCONFPATH}autoreconf"
  
  # func_usage
***
*** 1619,1626 
  
# Create autogenerated files.
(cd "$megatestdir"
!echo "executing ${AUTORECONF} --install"
!${AUTORECONF} --install
)
  }
  
--- 1625,1641 
  
# Create autogenerated files.
(cd "$megatestdir"
!# Do not use "${AUTORECONF} --install", because autoreconf operates
!# recursively, but the subdirectories are already finished, therefore
!# calling autoreconf here would only waste lots of CPU time.
!echo "executing ${ACLOCAL}"
!${ACLOCAL}
!echo "executing mkdir build-aux"
!mkdir build-aux
!echo "executing ${AUTOCONF}"
!${AUTOCONF}
!echo "executing ${AUTOMAKE} --add-missing --copy"
!${AUTOMAKE} --add-missing --copy
)
  }
  




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

bug in mathl module

[Bruno Haible]

$ gnulib-tool --create-testdir --dir=testdir mathl
...
executing autoreconf --force --install
lib/Makefile.am:28: noinst_HEADERS must be set with `=' before using `+='
autoreconf: automake failed with exit status: 1

Should the module description use EXTRA_DIST instead of noinst_HEADERS?
Well, noinst_HEADERS explains more precisely the purpose of the files. So
I'm changing gnulib-tool:

2006-01-08  Bruno Haible  <[EMAIL PROTECTED]>

* gnulib-tool (func_emit_lib_Makefile_am, func_emit_tests_Makefile_am):
Initialize also noinst_HEADERS to empty.

*** gnulib-tool.bak 2006-01-08 13:30:35.0 +0100
--- gnulib-tool 2006-01-08 16:23:19.0 +0100
***
*** 688,693 
--- 688,694 
echo
echo "${libname}_${libext}_SOURCES ="
echo "${libname}_${libext}_LIBADD = @${perhapsLT}LIBOBJS@"
+   echo "noinst_HEADERS ="
echo "EXTRA_DIST ="
echo "BUILT_SOURCES ="
echo "SUFFIXES ="
***
*** 761,766 
--- 762,768 
echo "TESTS ="
echo "TESTS_ENVIRONMENT ="
echo "noinst_PROGRAMS ="
+   echo "noinst_HEADERS ="
echo "EXTRA_DIST ="
echo "BUILT_SOURCES ="
echo "SUFFIXES ="




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

bug in gc-des module

[Bruno Haible]

The des_setkey function still collides with the one on MacOS X:

gcc -DHAVE_CONFIG_H -I. -I../../../megatestdir/gc-des/lib -I.. -g -O2 -c 
../../../megatestdir/gc-des/lib/gc-gnulib.c
In file included from ../../../megatestdir/gc-des/lib/gc-gnulib.c:65:
../../../megatestdir/gc-des/lib/des.h:62: error: conflicting types for 
`des_setkey'
/usr/include/unistd.h:196: error: previous declaration of `des_setkey'
make[4]: *** [gc-gnulib.o] Error 1

Bruno




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES.html

[Bruno Haible]

Paul Eggert wrote:
> I thought this module might be useful for people trying to build
> executables on systems like Solaris where the "-lrt" option causes the
> executable to dynamically link to rt, even if the executable does not
> need any of the rt routines.

The problem is brought in by the fact that we build a single libgnulib or
libcoreutils for all executables of a package, and if a single function
in this library needs, say, high-resolution timers, the libgnulib or
libcoreutils has "-lrt" in its link specification. Unfortunately, I know
no better solution than yours.

> +   [gl_ldd_output0=`(ldd conftest$ac_exeext) 2>/dev/null` ||

This uses 'ldd'. This command is OS dependent:

   AIX:  dump -H
   IRIX: elfdump -Dl
   HP-UX:chatr
   OSF/1, Tru64: odump -Dl
   Solaris:  ldd
   glibc-based:  ldd

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

warning in 'base64' module

[Bruno Haible]

The base64 module has a warning on Linux/glibc:

gcc -DHAVE_CONFIG_H -I. -I/packages/megatestdir/base64/lib -I.. -g -O2 -c 
/packages/megatestdir/base64/lib/base64.c
/packages/megatestdir/base64/lib/base64.c: In function `isbase64':
/packages/megatestdir/base64/lib/base64.c:284: warning: comparison is always 
true due to limited range of data type

Bruno




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: getprogname

[Bruno Haible]

> > How about this proposal?
> >
> > * Change the progname module to use the BSD getprogname naming
> >   convention.  No sense reinventing the wheel.  That way, programs can
> >   simply use the system-defined functions on BSD.
> >
> > * Rewrite the other gnulib code to use the new convention.
> >
> > * Ask gnulib users to switch to the new convention.
>
> Yes, that's the most sensible thing to do.

It is not so easy.

There are two problems:

1) BSD error handling routines use getprogname()
 = essentially base_name(argv[0]).

   GNU error handling routines use
 program_name = essentially argv[0]
 likewise on glibc: program_invocation_name, not
 program_invocation_short_name

   You can see the visible difference in behaviour on a MacOS X machine
   which has a BSD 'mv' in /bin/mv and a GNU 'mv' too:

 $ /bin/mv junk /etc/
 mv: rename junk to /etc/junk: Permission denied
 $ /gnu/bin/mv junk /etc/
 /gnu/bin/mv: Verschieben von „junk“ nach „/etc/junk“ nicht möglich: 
Permission denied

   I find the GNU behaviour better designed, because when a program is
   called with a full or relative pathname, it's usually because it's
   not in PATH or not the first one in PATH, and the GNU error handling
   gives more information as of which 'mv' program gave the error message.
   Whereas BSD's error handling behaviour makes the user think that the
   error message came from "the" 'mv' program - although "the" 'mv' in
   my PATH is actually /gnu/bin/mv.

2) getprogname() returns something different than the argument of
   setprogname(). Would be acceptable if the difference was small, but
   as 1) shows, it does matter.

We have 4 options:

  a) Change the behaviour of error() to be like on BSD, using
 the equivalent of program_invocation_short_name instead of
 the equivalent of program_invocation_name.

  b) Add an accessor function getprogpath() or similar, that is
 then used by error.c.

  c) Add an accessor function getprogbasename() or similar, that
 corresponds to what BSD getprogname() does, and change getprogname()
 to be like program_invocation_name.

  d) Don't try to emulate the BSD API at all. Use function names like
   set_program_name()
   get_program_name()
   get_program_base_name() or get_program_short_name().

The drawback of a) is less transparency for the end user, and a different
behaviour than glibc.

The drawback of b) is that it's confusing for the developer:
getprogpath() returns the value set with setprogname(), and getprogname()
returns something different.

The drawback of c) is that our functions have the same names as the BSD
ones but do something different.

My vote is therefore for d).

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: autoreconf is recursive

[Bruno Haible]

Ralf Wildenhues wrote:
> It would be nice if you could make the $AUTO* variables overridable on a
> case by case basis.  Tools are named differently at places, e.g.,
> autoconf25.

Will this work for the situation that you have in mind?

Bruno


*** gnulib-tool.orig 11 Jan 2006 13:03:25 -  1.99
--- gnulib-tool 11 Jan 2006 16:28:36 -
***
*** 38,47 
  # You can set AUTOMAKEPATH to empty if automake 1.9.x is already in your PATH.
  AUTOMAKEPATH=
  
! AUTOCONF="${AUTOCONFPATH}autoconf"
! ACLOCAL="${AUTOMAKEPATH}aclocal"
! AUTOMAKE="${AUTOMAKEPATH}automake"
! AUTORECONF="${AUTOCONFPATH}autoreconf"
  
  # func_usage
  # outputs to stdout the --help usage message.
--- 38,57 
  # You can set AUTOMAKEPATH to empty if automake 1.9.x is already in your PATH.
  AUTOMAKEPATH=
  
! # If you didn't set AUTOCONFPATH and AUTOMAKEPATH, you can also set the
! # variables AUTOCONF, ACLOCAL, AUTOMAKE, AUTORECONF individually.
! if test -z "${AUTOCONF}" || test -n "${AUTOCONFPATH}"; then
!   AUTOCONF="${AUTOCONFPATH}autoconf"
! fi
! if test -z "${ACLOCAL}" || test -n "${AUTOMAKEPATH}"; then
!   ACLOCAL="${AUTOMAKEPATH}aclocal"
! fi
! if test -z "${AUTOMAKE}" || test -n "${AUTOMAKEPATH}"; then
!   AUTOMAKE="${AUTOMAKEPATH}automake"
! fi
! if test -z "${AUTORECONF}" || test -n "${AUTOCONFPATH}"; then
!   AUTORECONF="${AUTOCONFPATH}autoreconf"
! fi
  
  # func_usage
  # outputs to stdout the --help usage message.



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: Separate csharpcomp.sh, and a license problem

[Bruno Haible]

Simon Josefsson wrote:
> AC_CONFIG_FILES([csharpcomp.sh:build-aux/csharpcomp.sh.in])
>
> is the best default.   It seem to cause csharpcomp.sh to end up in the
> top-level directory.  I don't like this.

libtool does the same.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: warning in 'base64' module

[Bruno Haible]

Simon Josefsson wrote:
> bool
> isbase64 (char ch)
> {
>   return to_uchar (ch) <= 255 && 0 <= b64[to_uchar (ch)];
> }
> ...
> Presumably the warning is because gcc believe an unsigned char cannot
> be larger than 255, but we didn't want to assume that since I don't
> think C89 guarantee it.  Correct me if I'm wrong...
>
> Is there a clean fix?

bool
isbase64 (char ch)
{
  return
 #if UCHAR_MAX > 255
 to_uchar (ch) <= 255
 #else
 true
 #endif
 && 0 <= b64[to_uchar (ch)];
}

or

bool
isbase64 (char ch)
{
  #if UCHAR_MAX > 255
  if (to_uchar (ch) > 255)
return false;
  #endif
  return 0 <= b64[to_uchar (ch)];
}

Ugly, but a warning on which people stumble over and over again (because
it appears even without -Wall) is even worse. I work around this kind of
warning also in GNU gettext.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: autoreconf is recursive

[Bruno Haible]

Simon Josefsson wrote:
> Is it really safe to avoid to regenerate in sub-directories?

Yes, since they have been generated through func_create_testdir.

> I think this should be considered a autoreconf bug and reported
> though. ... If so, perhaps autoreconf should have a --no-recursion or
> similar?

Good idea. I'm asking on the autoconf mailing list. Sorry I forgot to
mention that it was your idea. Apologies.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES.html

[Bruno Haible]

Paul Eggert wrote:
> If a package like that defines several programs,
> only some of which call clock_gettime, then the maintainer will have
> to do something like this (this is an extract from
> coreutils/src/Makefile.am):
>
> pr_LDADD = $(LDADD) $(LIB_CLOCK_GETTIME)
> shred_LDADD = $(LDADD) $(LIB_GETHRXTIME) $(LIB_FDATASYNC)
> sort_LDADD = $(LDADD) $(POW_LIB) $(LIB_GETHRXTIME)
> ...
>
> where each program is carefully linked to each optionally-available
> library it might use.

Yes, that's the state-of-the-art technique. It's tedious but reliable.

> This sort of cataloging is error-prone and a pain to maintain.  It
> should be automated, and -zignore does the automation.

Is -zignore fully portable? If you find only a single platform where
-zignore's functionality does not exist, then you need to go back to the
explicit list of potential dependencies.

>   if test "$gl_ldd_output0"; then

The autoconf manual recommends   test -n "$gl_ldd_output0"   here.

> test "$gl_ldd_output0" != "$gl_ldd_output1" then

I'm not sure that all 'ldd' variants will keep the output the same when
the set of dependent libraries has not changed. Some also include hexadecimal
addresses in the output, I think.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

new module 'ldd'

[Bruno Haible]

Hi,

gnulib is a portability library, and "ldd" is not portable. So I'm adding
the following module 'ldd'.

2006-01-12  Bruno Haible  <[EMAIL PROTECTED]>

* modules/ldd: New file.
* m4/ldd.m4: New file.
* build-aux/ldd.sh.in: New file.
* MODULES.html.sh (Support for building libraries and executables): Add
ldd.

=== modules/ldd ===
Description:
Command to determine the dynamically linked dependencies of a program.

Files:
build-aux/ldd.sh.in
m4/ldd.m4

Depends-on:

configure.ac:
gl_LDD
AC_CONFIG_FILES([ldd.sh:build-aux/ldd.sh.in])

Makefile.am:

Include:

License:
GPLed build tool

Maintainer:
Bruno Haible

 m4/ldd.m4 
# ldd.m4 serial 1
dnl Copyright (C) 2006 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.

# Sets LDDPROG to a command and LDDPOSTPROC to a filter command, such that
#   $LDDPROG program $LDDPOSTPROC
# outputs a whitespace-separated list of the dynamically linked dependencies
# of the program, as library names (no full pathnames), or nothing if the
# program is statically linked or if the service is not supported on the given
# system.

dnl From Bruno Haible.

AC_DEFUN([gl_LDD],
[
  AC_REQUIRE([AC_CANONICAL_HOST])
  AC_REQUIRE([AC_PROG_CC])
  dnl Default values.
  LDDPROG=':'
  LDDPOSTPROC=
  dnl First try objdump, since it works when cross-compiling.
  AC_CHECK_TOOL([OBJDUMP], [objdump], [:])
  if test "$OBJDUMP" != ":"; then
LDDPROG="LC_ALL=C $OBJDUMP -p"
dnl The output of "LC_ALL=C objdump -p program" of a program or library
dnl looks like this:
dnl
dnl libnet.so: file format elf32-i386
dnl
dnl Program Header:
dnl LOAD off0x vaddr 0x paddr 0x align 2**12
dnl  filesz 0x0001391d memsz 0x0001391d flags r-x
dnl LOAD off0x00013920 vaddr 0x00014920 paddr 0x00014920 align 2**12
dnl  filesz 0x1874 memsz 0x0001b020 flags rw-
dnl  DYNAMIC off0x00015104 vaddr 0x00016104 paddr 0x00016104 align 2**2
dnl  filesz 0x0090 memsz 0x0090 flags rw-
dnl
dnl Dynamic Section:
dnl   NEEDED  libroot.so
dnl   SONAME  libnet.so
dnl   SYMBOLIC0x0
dnl   INIT0x2aec
dnl   FINI0x12a2c
dnl   HASH0x94
dnl   STRTAB  0x1684
dnl   SYMTAB  0x774
dnl   STRSZ   0xbd5
dnl   SYMENT  0x10
dnl   PLTGOT  0x15f20
dnl   PLTRELSZ0x320
dnl   PLTREL  0x11
dnl   JMPREL  0x27cc
dnl   REL 0x225c
dnl   RELSZ   0x570
dnl   RELENT  0x8
LDDPOSTPROC="2>/dev/null | sed -n -e 's,^  NEEDED *\\([^ ].*\\)\$,\\1,p'"
  else
if test "$cross_compiling" = no; then
  dnl Not cross-compiling. Try system dependent vendor tools.
  case "$host_os" in
aix*)
  LDDPROG="LC_ALL=C dump -H"
  dnl The output of "LC_ALL=C dump -H program" looks like this:
  dnl
  dnl program:
  dnl
  dnl ***Loader Section***
  dnl   Loader Header Information
  dnl VERSION# #SYMtableENT #RELOCentLENidSTR
  dnl 0x0001   0x0005   0x000d   0x001e 
  
  dnl 
  dnl #IMPfilIDOFFidSTR LENstrTBLOFFstrTBL
  dnl 0x0002   0x0134   0x000d   0x0152 
  
  dnl 
  dnl 
  dnl ***Import File Strings***
  dnl INDEX  PATH  BASEMEMBER   
   
  dnl 0  /usr/lib:/lib  
   
  dnl 1libc.a  shr.o
   
  dnl
  LDDPOSTPROC="2>/dev/null | sed -e '/^[^0-9]/d' -e '/^0x/d' | sed -n 
-e 's,^[0-9]* *\\([^  ]*\\).*\$,\\1,p' | sed -e 's,^.*/,,'"
  ;;
darwin*)
  LDDPROG="otool -L"
  dnl The output of "otool -L program" looks like this:
  dnl program:
  dnl /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 71.1.4)
  LDDPOSTPROC="2>/dev/null | sed -n -e 's,^ \\([^   
]*\\).*\$,\\1,p' | sed -e 's,^.*/,,'"
  ;;
hpux*)
  LDDPROG="LC_ALL=C chatr"
  dnl The output of "LC_ALL=C chatr program" lo

Re: [bug-gnulib] Re: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES.html

[Bruno Haible]

Paul Eggert wrote:
> +   [for gl_ldd in \
> + ldd \
> + 'chatr' \
> + 'dump -H' \
> + 'elfdump -Dl' \
> + 'odump -Dl' \
> + 'otool -L' \
> + :; do
> +   gl_ldd_output0=`($gl_ldd conftest$ac_exeext) 2>/dev/null` && break
> +done])

This code probably won't work when cross-compiling, because it mixes
host platform and target tools.

If you use the new 'ldd' module, it
  - should work also when cross-compiling,
  - should be immune to changed addresses in the output of 'chatr',
'dump -H', 'elfdump -Dl', 'ldd', 'odump -Dl',
  - simply feels safer to use the appropriate command for each system,
rather than trying "chatr" or "odump" on every system.

To use the 'ldd' module is simple:
  - add an AC_REQUIRE([gl_LDD]),
  - use
 $LDDPROG conftest$ac_exeext $LDDPOSTPROC
instead of
 ($gl_ldd conftest$ac_exeext) 2>/dev/null

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: new module 'ldd'

[Bruno Haible]

Ralf Wildenhues wrote:
> >   AC_CHECK_TOOL([OBJDUMP], [objdump], [:])
>
> This will conflict with libtool-set $OBJDUMP in packages that use
> libtool.  Libtool currently uses
>   AC_CHECK_TOOL([OBJDUMP], [objdump], [false])

OK, I'm changing ldd.m4 to use the same.

> This is not portable to packages that use libtool.

Do you see other incompatibilities?

The fact that a libtool created "program" is not actually a program but a
script, is a problem of libtool. Fix that, then we can also use
"gdb program" instead of the surprising syntax "libtool gdb program".

> > LDDPROG="LC_ALL=C $OBJDUMP -p"
>
> I'd rather put the LC_ALL=C elsewhere.  configure scripts set this by
> default already.  Your shell wrapper could trivially set this before
> invoking the tool.

The LDDPROG can also be used outside the shell wrapper, by other macros
or Makefile commands, where LC_ALL=C is not necessarily guaranteed. But
it will probably not hurt if I put LC_ALL=C before any LDDPROG value.

Bruno


--- ldd.m4  12 Jan 2006 18:04:16 -  1.3
+++ ldd.m4  12 Jan 2006 18:06:59 -
@@ -24,7 +24,7 @@
   AC_CHECK_TOOL([OBJDUMP], [objdump], [false])
 changequote(,)dnl
   if test "$OBJDUMP" != "false"; then
-LDDPROG="LC_ALL=C $OBJDUMP -p"
+LDDPROG="$OBJDUMP -p"
 dnl The output of "LC_ALL=C objdump -p program" of a program or library
 dnl looks like this:
 dnl
@@ -62,7 +62,7 @@
   dnl Not cross-compiling. Try system dependent vendor tools.
   case "$host_os" in
 aix*)
-  LDDPROG="LC_ALL=C dump -H"
+  LDDPROG="dump -H"
   dnl The output of "LC_ALL=C dump -H program" looks like this:
   dnl
   dnl program:
@@ -91,7 +91,7 @@
   LDDPOSTPROC="2>/dev/null | sed -n -e 's,^\\([^   
]*\\).*\$,\\1,p' | sed -e 's,^.*/,,'"
   ;;
 hpux*)
-  LDDPROG="LC_ALL=C chatr"
+  LDDPROG="chatr"
   dnl The output of "LC_ALL=C chatr program" looks like this:
   dnl program: 
   dnl  shared executable 
@@ -166,14 +166,14 @@
   LDDPOSTPROC="2>/dev/null | sed -n -e 's,^[[][0-9]*[]].*  0x[^
]*  [^  ][^ ]*  \\([^   ][^ ]*\\).*\$,\\1,p' | sed -e 
's,^.*/,,'"
   ;;
 linux* | gnu* | kfreebsd*-gnu | knetbsd*-gnu) # glibc-based systems
-  LDDPROG="LC_ALL=C ldd"
+  LDDPROG="ldd"
   dnl The output of "ldd program" looks like this:
   dnl libc.so.6 => /lib/libc.so.6 (0x4002d000)
   dnl /lib/ld-linux.so.2 (0x4000)
   LDDPOSTPROC="2>/dev/null | sed -n -e 's,^\\([^   ][^ 
]*\\).*\$,\\1,p' | sed -e 's,^.*/,,'"
   ;;
 osf*)
-  LDDPROG="LC_ALL=C odump -Dl"
+  LDDPROG="odump -Dl"
   dnl The output of "odump -Dl program" looks like this:
   dnl
   dnl ***LIBRARY LIST SECTION***
@@ -184,7 +184,7 @@
   LDDPOSTPROC="2>/dev/null | sed -n -e 's,^\\([^   ][^ 
]*\\).*,\\1,p' | sed -e '/^Name\$/d' | sed -e 's,^.*/,,'"
   ;;
 solaris*)
-  LDDPROG="LC_ALL=C ldd"
+  LDDPROG="ldd"
   dnl The output of "ldd program" looks like this:
   dnl libc.so.1 => /usr/lib/libc.so.1
   dnl libdl.so.1 =>/usr/lib/libdl.so.1
@@ -197,6 +197,10 @@
   esac
 fi
   fi
+  dnl Avoid locale dependencies.
+  if test "$LDDPROG" != ":"; then
+LDDPROG="LC_ALL=C $LDDPROG"
+  fi
 changequote([,])dnl
   AC_SUBST([LDDPROG])
   AC_SUBST([LDDPOSTPROC])



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: new module 'ldd'

[Bruno Haible]

Ralf Wildenhues wrote:
> > The LDDPROG can also be used outside the shell wrapper, by other macros
> > or Makefile commands, where LC_ALL=C is not necessarily guaranteed. But
> > it will probably not hurt if I put LC_ALL=C before any LDDPROG value.
>
> Yes, good argument.  I think it would be even better to use
>   LDDPROG="env LC_ALL=C $LDDPROG"
>
> to facilitate `exec $LDDPROG', and other situations where the first
> component is really supposed to be a program.  You could use exec in
> ldd.sh.

I cannot use exec in ldd.sh, since the output of the command is piped
through a sed command.

Even if I could use exec there, "exec env LC_ALL=C $LDDPROG" is slower
than "LC_ALL=C $LDDPROG", because "env" costs 1 fork() and 1 exec()
whereas "exec" optimizes away only the fork() - the exec() remains
additional burden. The optimal way to write it in this case is
"LC_ALL=C exec $LDDPROG".

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: new module 'ldd'

[Bruno Haible]

[redirected to bug-libtool, from bug-gnulib]
Ralf Wildenhues wrote:

> > The fact that a libtool created "program" is not actually a program but a
> > script, is a problem of libtool. Fix that, then we can also use
> > "gdb program" instead of the surprising syntax "libtool gdb program".
>
> Two comments: I have yet to see a proposal how uninstalled programs may
> load uninstalled libraries on all systems, without using a wrapper of
> some sort.

Here is a proposal that works on glibc systems and possibly other systems:
Create the uninstalled program in the current directory, with -rpath
linker options that refer to directories containing uninstalled libraries.

During installation "libtool --mode=install" will have to create a
different executable, with different -rpath options.

This works on glibc systems because the -rpath directories have
precedence over the LD_LIBRARY_PATH directories.

The most important Unix systems (Linux, Solaris, HP-UX, AIX, IRIX, OSF/1,
FreeBSD, OpenBSD, NetBSD) all support -rpath or equivalent for executables.
But on some the precedence is reversed, for example on IA64 HP-UX,
the LD_LIBRARY_PATH is consulted before the embedded rpath. On these
systems my proposal will not work.

> Note on some systems (GNU/Linux/GCC for example) there is
> a trade-off to make wrt. fast-install

Being a developer, I'm asking to make the trade-offs in favour of the
developer's comfort, i.e. optimized for "make", "gdb", and "make check",
at the expense of a slower "make install" :-)

> So, no, I don't acknowledge that as bug, but as (necessary) limitation.

glibc systems are the platforms on which most of us are developing. Isn't
it worth to optimize libtool for these platforms?

> (Your unrelated issue about the last path component of argv[0] starting
> with `lt-' is a different beast: it's a bug I'd like to fix eventually.)

Thanks in advance!

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: inet_ntop fix for mingw32

[Bruno Haible]

Simon Josefsson wrote:
> I installed this patch:
>
> Index: modules/socklen
> ===
> RCS file: /sources/gnulib/gnulib/modules/socklen,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -p -r1.2 -r1.3
> --- modules/socklen   15 Dec 2005 09:13:08 -  1.2
> +++ modules/socklen   17 Jan 2006 17:22:37 -  1.3
> @@ -12,6 +12,7 @@ gl_TYPE_SOCKLEN_T
>  Makefile.am:
>
>  Include:
> +#include 
>
>  License:
>  unlimited

Then 'socklen' should also have a dependency on 'sys_socket'.

> > Similarly, I propose to modify modules/ssize as follows:
>
> Looks good, please install.

OK, I commit it.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: inet_ntop fix for mingw32

[Bruno Haible]

Simon Josefsson wrote:
> >> +#include 
> >>
> >>  License:
> >>  unlimited
> >
> > Then 'socklen' should also have a dependency on 'sys_socket'.
>
> I'm not sure.  It gets ugly if no modules can assume sys/socket.h
> without depending on sys_socket?

That's the point of the sys_socket module.

If you don't have sys_socket module, you have to write

#if HAVE_SYS_SOCKET_H
#include 
#endif

If you have the sys_socket module, you can simplify it to

#include 

It's the same logic as with , ,  and others:
If you don't have a dependency on the module that provides the substitute,
you cannot use the header file unconditionally.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: new module lib-ignore; new section build_lib in MODULES.html

[Bruno Haible]

Paul Eggert wrote:
> Stepping back from things a bit, I discovered a way to simplify
> lib-ignore so that it no longer needs to use ldd.  Instead, it merely
> uses the '-z ignore' option if this works.

All the better.

One more question about this macro: What is the difference between
-Xlinker and -Wl (apart from the slightly different syntax)? libtool and
config.rpath sometimes use -Wl to pass an option to the linker and never
-Xlinker, whereas your macro uses sometimes -Xlinker and never -Wl.
It appears that -Xlinker is supported only by gcc, and -Wl by other
compilers too?

> I looked into doing this, and ran into some problems.
> LDDPOSTPROC is set in such a way that configure needs to employ 'eval'
> to use it, and then I ran into porting problems when using things like
> 'eval "$LDDPROG ... $LDDPOSTPROC"' since LDDPROG began "LC_ALL=C ..."

The variables were not meant to be used with eval, just to be used
without quotes, like this:
 $LDDPROG program $LDDPOSTPROC

Which problem did you run into?

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] getaddrinfo: finding gethostbyname in mingw32

[Bruno Haible]

Simon Josefsson wrote:
> My problem is getting
> AC_SEARCH_LIBS to find functions in the mingw32 libraries.  It seems a
> __stdcall is required in the prototype to make it link correctly.

The prototype with __stdcall must be contained in a public include file,
no? (, included by your  substitute.)
It seems you will have to write a test that
  1) tries to use gethostbyname() with the #include and no additional libraries,
  2) same thing with -lwsock32,
and set some LIB* or *_LDFLAGS variable, depending on the result.
Look how AM_ICONV_LINK (in gethostbyname.m4) does it; something like
this:

  AC_CACHE_CHECK(for gethostbyname, gl_cv_func_gethostbyname, [
gl_cv_func_gethostbyname=no
gl_cv_lib_gethostbyname=no
AC_TRY_LINK([
#if HAVE_SYS_SOCKET_H
# include 
#elif HAVE_WINSOCK2_H
# include 
#endif],
  [gethostbyname("");],
  gl_cv_func_gethostbyname=yes)
if test "$gl_cv_func_gethostbyname" != yes; then
  am_save_LIBS="$LIBS"
  LIBS="$LIBS -lwsock32"
  AC_TRY_LINK([
#if HAVE_SYS_SOCKET_H
# include 
#elif HAVE_WINSOCK2_H
# include 
#endif],
[gethostbyname("");],
gl_cv_lib_gethostbyname=yes
gl_cv_func_gethostbyname=yes)
  LIBS="$am_save_LIBS"
fi
  ])

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: inet_ntop fix for mingw32

[Bruno Haible]

Simon Josefsson wrote:
> This fixes the socklen M4 test.  It more or less duplicate the
> sys_socket module but I don't see any other way around it.

Duplication of code always leads to maintenance problems. Not sometimes.
Always. (I tried it often enough ;-))

Already in this patch it is not clear why the replacement socket_.h
includes  but socklen.m4 doesn't. It is probably because
on current mingw systems,  doesn't define socklen_t.
They only need to reshuffle their include files a bit, to break
our macro.

How about this? (Untested.)

Bruno


*** socklen.m4  2 Dec 2005 18:23:00 -   1.3
--- socklen.m4  18 Jan 2006 13:08:44 -
***
*** 1,5 
! # socklen.m4 serial 2
! dnl Copyright (C) 2005 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.
--- 1,5 
! # socklen.m4 serial 3
! dnl Copyright (C) 2005-2006 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.
***
*** 11,17 
  dnl types for the argument to getsockopt, getpeername, etc.  So we
  dnl have to test to find something that will work.
  AC_DEFUN([gl_TYPE_SOCKLEN_T],
!   [AC_CHECK_TYPE([socklen_t], ,
   [AC_MSG_CHECKING([for socklen_t equivalent])
AC_CACHE_VAL([gl_cv_gl_cv_socklen_t_equiv],
  [# Systems have either "struct sockaddr *" or
--- 11,18 
  dnl types for the argument to getsockopt, getpeername, etc.  So we
  dnl have to test to find something that will work.
  AC_DEFUN([gl_TYPE_SOCKLEN_T],
!   [AC_REQUIRE([gl_HEADER_SYS_SOCKET])
!AC_CHECK_TYPE([socklen_t], ,
   [AC_MSG_CHECKING([for socklen_t equivalent])
AC_CACHE_VAL([gl_cv_gl_cv_socklen_t_equiv],
  [# Systems have either "struct sockaddr *" or
***
*** 21,28 
   for t in int size_t "unsigned int" "long int" "unsigned long int"; do
 AC_TRY_COMPILE(
   [#include 
!   #include 
! 
int getpeername (int, $arg2 *, $t *);],
 [$t len;
getpeername (0, 0, &len);],
--- 22,32 
   for t in int size_t "unsigned int" "long int" "unsigned long int"; do
 AC_TRY_COMPILE(
   [#include 
!   #if HAVE_SYS_SOCKET_H
!   # include 
!   #else
!   # include "socket_.h"
!   #endif
int getpeername (int, $arg2 *, $t *);],
 [$t len;
getpeername (0, 0, &len);],




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: getaddrinfo: finding gethostbyname in mingw32

[Bruno Haible]

Simon Josefsson wrote:
>   AC_SEARCH_LIBS(gethostbyname, [inet nsl])
> ...
>   if test "$ac_cv_search_gethostbyname" = "no"; then
> save_LIBS="$LIBS"
> LIBS="$LIBS -lwsock32"
> AC_MSG_CHECKING([whether we need -lwsock32])
> AC_LINK_IFELSE([
>   AC_LANG_PROGRAM([[
> #include 

Why do you include , when the declaration is actually in
? (At least it is in the mingw version I'm looking at.)

> ]], [gethostbyname ("foo");])],
>   need_wsock32=yes, need_wsock32=no)
> AC_MSG_RESULT($need_wsock32)
> LIBS="$save_LIBS"
> if test "$need_wsock32" = "yes"; then
>   LIBS="$LIBS -lwsock32"
> fi
>   fi
>
> However, it seems rather ugly.

No, it's fine: It adds to LIBS only what is needed. It works when
cross-compiling. It uses the same technique as AC_SEARCH_LIBS.

> I was hoping to be able to connect to
> the AC_SEARCH_LIB logic somehow

You are only working around the lack of a #includes section argument
in the AC_SEARCH_LIBS macro.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] --avoid with --extract-dependencies

[Bruno Haible]

Sergey Poznyakoff wrote:
> Shouldn't `--avoid' work with `--extract-dependencies'? I propose the
> following patch:

Thanks for the suggestion, but I don't think it fits well:
- The --extract-* modes are all intended as low-level facilities, just
  reading the contents of the module description.
- The --extract-* modes all take a single module as arguments. However,
  --avoid works during the recursive closure and therefore assumes
  multiple module names as input.

What exactly are you trying to do that --import and --update cannot do?

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: argp-fmtstream.h, localcharset.c

[Bruno Haible]

Karl Berry wrote:
> It seems gnulib changes have been made to argp-fmtstream.h,
> localcharset.c, previously synced from libc and gettext-runtime
> respectively.  Should I comment out the sync ?

Yes please.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

fix in vasnprintf.c

[Bruno Haible]

Hi,

I committed this patch in lib/vasnprintf.c. Fixes a too low estimate of
the size of an sprintf result, leading to a buffer overflow. Fortunately
most platforms have either a snprintf() or _snprintf() function, and
lib/vasnprintf.c uses this if available. Otherwise it would have been
a security problem...

Bruno


2006-01-22  Bruno Haible  <[EMAIL PROTECTED]>

* vasnprintf.c (VASNPRINTF): In the computation of the size of the
temporary buffer for sprintf, take into account the precision also
for 'd', 'i', 'u', 'o', 'x', 'X'.

*** lib/vasnprintf.cSat May 21 00:18:37 2005
--- lib/vasnprintf.cSun Jan 22 21:03:07 2006
***
*** 1,5 
  /* vsprintf with automatic memory allocation.
!Copyright (C) 1999, 2002-2005 Free Software Foundation, Inc.
  
 This program is free software; you can redistribute it and/or modify it
 under the terms of the GNU Library General Public License as published
--- 1,5 
  /* vsprintf with automatic memory allocation.
!Copyright (C) 1999, 2002-2006 Free Software Foundation, Inc.
  
 This program is free software; you can redistribute it and/or modify it
 under the terms of the GNU Library General Public License as published
***
*** 335,362 
tmp_length =
  (unsigned int) (sizeof (unsigned long long) * CHAR_BIT
  * 0.30103 /* binary -> decimal */
- * 2 /* estimate for FLAG_GROUP */
 )
! + 1 /* turn floor into ceil */
! + 1; /* account for leading sign */
  else
  # endif
  if (type == TYPE_LONGINT || type == TYPE_ULONGINT)
tmp_length =
  (unsigned int) (sizeof (unsigned long) * CHAR_BIT
  * 0.30103 /* binary -> decimal */
- * 2 /* estimate for FLAG_GROUP */
 )
! + 1 /* turn floor into ceil */
! + 1; /* account for leading sign */
  else
tmp_length =
  (unsigned int) (sizeof (unsigned int) * CHAR_BIT
  * 0.30103 /* binary -> decimal */
- * 2 /* estimate for FLAG_GROUP */
 )
! + 1 /* turn floor into ceil */
! + 1; /* account for leading sign */
  break;
  
case 'o':
--- 335,362 
tmp_length =
  (unsigned int) (sizeof (unsigned long long) * CHAR_BIT
  * 0.30103 /* binary -> decimal */
 )
! + 1; /* turn floor into ceil */
  else
  # endif
  if (type == TYPE_LONGINT || type == TYPE_ULONGINT)
tmp_length =
  (unsigned int) (sizeof (unsigned long) * CHAR_BIT
  * 0.30103 /* binary -> decimal */
 )
! + 1; /* turn floor into ceil */
  else
tmp_length =
  (unsigned int) (sizeof (unsigned int) * CHAR_BIT
  * 0.30103 /* binary -> decimal */
 )
! + 1; /* turn floor into ceil */
! if (tmp_length < precision)
!   tmp_length = precision;
! /* Multiply by 2, as an estimate for FLAG_GROUP.  */
! tmp_length = xsum (tmp_length, tmp_length);
! /* Add 1, to account for a leading sign.  */
! tmp_length = xsum (tmp_length, 1);
  break;
  
case 'o':
***
*** 366,373 
  (unsigned int) (sizeof (unsigned long long) * CHAR_BIT
  * 0.34 /* binary -> octal */
 )
! + 1 /* turn floor into ceil */
! + 1; /* account for leading sign */
  else
  # endif
  if (type == TYPE_LONGINT || type == TYPE_ULONGINT)
--- 366,372 
  (unsigned int) (sizeof (unsigned long long) * CHAR_BIT
  * 0.34 /* binary -> octal */

Re: $(EXEEXT) in TESTS required?

[Bruno Haible]

[For the automake people: The problem is that a Makefile.am snippet like

 TESTS = test-lock
 check_PROGRAMS = test-lock
 test_LOCK_LDFLAGS = -lmyspeciallib

when cross-compiling to mingw on a Unix system with 'wine', will cause
"make check" to build 'test-lock', rather than 'test-lock.exe', thus
executing a compile and link command line that ignores the specific
CPPFLAGS and LDFLAGS. The thread started at
http://lists.gnu.org/archive/html/bug-gnulib/2006-01/msg00175.html]

Ralf Wildenhues wrote:
> Now I wonder how to best "fix" this in Automake:
> - document the fact that $(EXEEXT) should be used in `TESTS', for the
>   benefit of cross-compilation,
> - have Automake rewrite TESTS to add $(EXEEXT) where appropriate (is
>   this possible in all cases?),

I'm in favour of the second choice, and I claim that it is possible in all
cases. Why? Look at the currently generated tests/Makefile.in:

...
noinst_PROGRAMS =
check_PROGRAMS = test-lock$(EXEEXT)

TESTS = test-lock

check-am: all-am
$(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
$(MAKE) $(AM_MAKEFLAGS) check-TESTS

check-TESTS: $(TESTS)
@failed=0; all=0; xfail=0; xpass=0; skip=0; \
...

What you see is:
1) $(TESTS) occurs as a dependency in a target.
2) automake has rewritten the check_PROGRAMS variable.


From 1) I conclude that the TESTS variable cannot contain shell escapes
like backquoted commands,
 `show-all-tests`
since they wouldn't work as target dependencies anyway.

Therefore automake can indeed add a variable am_TESTS_DEPENDENCIES
that is constructed from TESTS by adding $(EXEEXT) to all elements that
also occur in the original value of check_PROGRAMS (and maybe also
noinst_PROGRAMS - why not?). Then change

check-TESTS: $(TESTS)

into

check-TESTS: $(am_TESTS_DEPENDENCIES)

and you're done.


From 2) I conclude that it would even be acceptable to change the TESTS
variable itself, to assume the contents of am_TESTS_DEPENDENCIES.


Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] tls-tests and lock-tests

[Bruno Haible]

Simon Josefsson wrote:
>  2006-01-19  Simon Josefsson  <[EMAIL PROTECTED]>
>
> + * modules/lock-tests, modules/tls-tests: Use check_PROGRAMS
> + instead of noinst_PROGRAMS to be able to remove test_*_SOURCES.
> +

Thanks, I have applied the uncontroversial part of it, not the $(EXEEXT),
which is still under discussion.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] socket.h

[Bruno Haible]

Simon Josefsson wrote:
> +#if !defined(SHUT_WR) && defined (SD_SEND)
> +# define SHUT_WR 1
> +#endif
> +#if !defined(SHUT_RDWR) && defined (SD_BOTH)
> +# define SHUT_RDWR 2
> +#endif

Is SD_SEND == 1 and SD_BOTH == 2 ?

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: socket.h

[Bruno Haible]

Paul Eggert wrote:
> I don't see any technical reason to prefer the parentheses.

While I agree that there are no technical reason to put the parentheses,
I wouldn't be religious on the issue, because the majority of the C
programmers does it the other way. The same argument as for "const char *":
http://lists.gnu.org/archive/html/bug-gnulib/2006-01/msg00024.html

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: $(EXEEXT) in TESTS required?

[Bruno Haible]

Ralf Wildenhues wrote:
> > check_PROGRAMS = test-lock$(EXEEXT)
> >
> > TESTS = test-lock
> ...
> What about @substituted@ values?

TESTS = @substituted@

You could treat it like @substituted@ in check_PROGRAMS, namely
  - assume that $(EXEEXT) is contained in the substituted value,
  - warn if EXTRA_PROGRAMS is not defined. (For
  check_PROGRAMS = @substituted@
automake gives an error if EXTRA_PROGRAMS is not defined; I think here
a warning would be appropriate).

> > From 2) I conclude that it would even be acceptable to change the TESTS
> > variable itself, to assume the contents of am_TESTS_DEPENDENCIES.
>
> If I see correctly that would allow Automake to kill this line
> completely (were it not for my question above):
> > $(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)

Yes, I agree. The current wording in the automake doc doesn't say
that all $(check_PROGRAMS) are build before all tests are executed, therefore
someone who writes

check_PROGRAMS = foo bar# foo, when run, calls bar
TESTS = foo

is already relying on "make" to have built the 'bar' program;
"make check" will not check its status again.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: $(EXEEXT) in TESTS required?

[Bruno Haible]

Ralf Corsepius wrote:
> Due to lack of a mingw toolchain, I can't tell you exactly what goes
> wrong for you.
>
> 3 likely candidates:
> * The cross gcc doesn't produce *.exe's (This would be a gcc bug).
> * You are not correctly invoking configure.
> * Makefile bug somewhere.

Is there need to hypothetize at this point? I found Simon's analysis in
http://lists.gnu.org/archive/html/bug-gnulib/2006-01/msg00189.html
pretty convincing.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] lib/stdbool_.h doesn't honor HAVE__BOOL

[Bruno Haible]

Albert Chin wrote:
> The HP-UX 11.23/IA aCC6 compiler has bool and _Bool. This generates an
> error building something that includes gnulib's auto-generated stdbool.h:
>   "../include/stdbool.h", line 84: error #2084: invalid combination of
>   type specifiers
> typedef bool _Bool;
>  ^
>
> Patch below fixes this.

Thanks, I've applied an equivalent of your patch. Sorry for the extremely
long delay.

Bruno


2006-01-24  Bruno Haible  <[EMAIL PROTECTED]>

* stdbool_.h (_Bool) [__cplusplus]: Don't define if the compiler already
has it.
Report and patch by Albert Chin-A-Young  <[EMAIL PROTECTED]> on
2005-11-26.

*** stdbool_.h  24 Jan 2006 21:44:37 -  1.7
--- stdbool_.h  24 Jan 2006 21:49:18 -
***
*** 70,76 
 (see ISO C 99 6.7.2.2.(4)); however, '_Bool' must promote to 'int'
 (see ISO C 99 6.3.1.1.(2)).  So we add a negative value to the
 enum; this ensures that '_Bool' promotes to 'int'.  */
! #if !(defined __cplusplus || defined __BEOS__)
  # if @HAVE__BOOL@
  #  if defined __HP_cc || defined __xlc__
  /* Some HP-UX cc and AIX IBM C compiler versions have compiler bugs when
--- 70,83 
 (see ISO C 99 6.7.2.2.(4)); however, '_Bool' must promote to 'int'
 (see ISO C 99 6.3.1.1.(2)).  So we add a negative value to the
 enum; this ensures that '_Bool' promotes to 'int'.  */
! #if defined __cplusplus || defined __BEOS__
!   /* A compiler known to have 'bool'.  */
!   /* If the compiler already has both 'bool' and '_Bool', we can assume they
!  are the same types.  */
! # if [EMAIL PROTECTED]@
! typedef bool _Bool;
! # endif
! #else
  # if @HAVE__BOOL@
  #  if defined __HP_cc || defined __xlc__
  /* Some HP-UX cc and AIX IBM C compiler versions have compiler bugs when
***
*** 91,98 
  typedef enum { _Bool_must_promote_to_int = -1, false = 0, true = 1 } _Bool;
  #  endif
  # endif
- #else
- typedef bool _Bool;
  #endif
  #define bool _Bool
  
--- 98,103 



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: removing unnecessary parentheses in #if defined (FOO)

[Bruno Haible]

Jim Meyering wrote:
> you must admit the
> parentheses in `#if defined (SYM)' add next to nothing in readability,
> and actually detract as soon as you end up adding another layer of
> parentheses:
>
>   #if (defined (S1) || defined (S2)) && defined (S3)

I agree with this. If this were the only piece of C code that exists,
then of course its readability would behave as you say.

The other point is that readability depends on what the reader is used to,
or is familiar with.

  you what than way opposite the in written is that sentence a Reading
  its do cannot brain reader's the because Simply .hard is to used are
   .way usual the matching pattern

This is also the reason for the existence of the GNU coding style: code
is easier to read if it follows the usual visual and semantic patterns.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] gnulib/gnulib-tool shell quoting problem for Solaris /bin/sh

[Bruno Haible]

Mark D. Baushke wrote:
> on a Solaris 9 system
> I have run into problems when /bin/sh is used.
>
> ...
>
> I am getting these two errors:
>
> sed: -e expression #1, char 2: unterminated `s' command
> ../gnulib/gnulib-tool: .*^I,,: not found
> sed: -e expression #1, char 2: unterminated `s' command
> ../gnulib/gnulib-tool: .*^I,,: not found
>
> I have tracked the problems down to the two for loops in this block of
> code starting on line 1152 in the gnulib-tool file:
>
>   # Then the files that are in new-files, but not in old-files:
>   already_present=
>   for f in `LC_ALL=C join -t"$delimiter" -v2 "$tmp"/old-files
> "$tmp"/new-files | sed -e 's,'^.*"$delimiter"',,'`; do case "$f" in
>   build-aux/*) g=`echo "$f" | sed -e "s,^build-aux/,$auxdir/,"` ;;
>   lib/*) g=`echo "$f" | sed -e "s,^lib/,$sourcebase/,"` ;;
>   m4/*) g=`echo "$f" | sed -e "s,^m4/,$m4base/,"` ;;
>   tests/*) g=`echo "$f" | sed -e "s,^tests/,$testsbase/,"` ;;
>   *) g="$f" ;;
> esac
> func_add_or_update
>   done
>   # Then the files that are in new-files and in old-files:
>   already_present=true
>   for f in `LC_ALL=C join -t"$delimiter" "$tmp"/old-files "$tmp"/new-files
> | sed -e 's,'^.*"$delimiter"',,'`; do case "$f" in
>   build-aux/*) g=`echo "$f" | sed -e "s,^build-aux/,$auxdir/,"` ;;
>   lib/*) g=`echo "$f" | sed -e "s,^lib/,$sourcebase/,"` ;;
>   m4/*) g=`echo "$f" | sed -e "s,^m4/,$m4base/,"` ;;
>   tests/*) g=`echo "$f" | sed -e "s,^tests/,$testsbase/,"` ;;
>   *) g="$f" ;;
> esac
> func_add_or_update
>   done
>
> The value of $delimeter is a control-I character.

Thanks for the report and patch. I've committed a patch equivalent to
yours.

> After using the patch, I only see the Solaris host adding one additional
> '-: not found' error message. For example, I see this on the Solaris 9
> host:
>
> % maint-aux/gnulib-update
> ../gnulib/gnulib-tool: -: not found
> 
> Makefile.am needs updating. Use `cvs diff lib/Makefile.gnulib' to
> view changes.
> 

To find out which command in gnulib-tool is causing this, you can
add a
set -x
command in line 22 of gnulib-tool, then run maint-aux/gnulib-update
again, and look where in the output you find the "-: not found" error
message. Thanks!

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: lib/stdbool_.h doesn't honor HAVE__BOOL

[Bruno Haible]

Paul Eggert wrote on 2005-11-26:
> Unfortunately that isn't enough to fix the stdbool module problems
> we've been running into recently with coreutils.  They include:
>
> Some HP-UX C compilers mishandle _Bool (internal compiler error),
> independently of whether  works.  E.g.,
> <http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html>,
> <http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html>.
>
> IBM C compiler mishandles sign-extension when combining _Bool with int. 
> E.g.,
> <http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html>.
>
> Some of the complexity of stdbool_.h is due to the desire to debug
> bool variables nicely with GDB, when you are using an older compiler
> that doesn't have a working .  That motivation is becoming
> more and more obsolescent these days, though, since most developers
> these days use compilers that support .  So I propose that
> we drop this as a goal for stdbool_.h.

Hmm, I'm not inclined to drop debuggability on platforms using gcc-2.95
or similar (such as OpenBSD 3.6), just for HP-UX and AIX compiler bugs.
I'm therefore applying the following minimal-change, punish-only-the-
broken-ones, patch.

Bruno


2006-01-24  Bruno Haible  <[EMAIL PROTECTED]>

* stdbool_.h (_Bool) [HP-UX cc, AIX cc,xlc] : Define as 'signed char'
to avoid problems with the built-in _Bool type.
Reported by Paul Eggert on 2005-11-26.

*** stdbool_.h  14 May 2005 06:03:58 -  1.6
--- stdbool_.h  24 Jan 2006 21:42:46 -
***
*** 1,4 
! /* Copyright (C) 2001, 2002, 2003 Free Software Foundation, Inc.
 Written by Bruno Haible <[EMAIL PROTECTED]>, 2001.
  
 This program is free software; you can redistribute it and/or modify
--- 1,4 
! /* Copyright (C) 2001, 2002, 2003, 2006 Free Software Foundation, Inc.
 Written by Bruno Haible <[EMAIL PROTECTED]>, 2001.
  
 This program is free software; you can redistribute it and/or modify
***
*** 71,77 
 (see ISO C 99 6.3.1.1.(2)).  So we add a negative value to the
 enum; this ensures that '_Bool' promotes to 'int'.  */
  #if !(defined __cplusplus || defined __BEOS__)
! # if [EMAIL PROTECTED]@
  #  if defined __SUNPRO_C && (__SUNPRO_C < 0x550 || __STDC__ == 1)
  /* Avoid stupid "warning: _Bool is a keyword in ISO C99".  */
  #   define _Bool signed char
--- 71,88 
 (see ISO C 99 6.3.1.1.(2)).  So we add a negative value to the
 enum; this ensures that '_Bool' promotes to 'int'.  */
  #if !(defined __cplusplus || defined __BEOS__)
! # if @HAVE__BOOL@
! #  if defined __HP_cc || defined __xlc__
! /* Some HP-UX cc and AIX IBM C compiler versions have compiler bugs when
!the built-in _Bool type is used.  See
!  http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
!  http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html
!  http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
!Override it.  */
! #   define _Bool signed char
! enum { false = 0, true = 1 };
! #  endif
! # else
  #  if defined __SUNPRO_C && (__SUNPRO_C < 0x550 || __STDC__ == 1)
  /* Avoid stupid "warning: _Bool is a keyword in ISO C99".  */
  #   define _Bool signed char



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: lib/stdbool_.h doesn't honor HAVE__BOOL

[Bruno Haible]

Paul Eggert wrote on 2005-11-26:
> Here is a proposed patch,
> which I've installed into coreutils (but not gnulib).

Thanks for the patch, and I'm sorry for the long delay in looking at it.

Two points that I don't understand:

>  /* BeOS  already #defines false 0, true 1.  We use the same
> -   definitions below, but temporarily we have to #undef them.  */
> +   definitions below, which is OK.  */
>  #ifdef __BEOS__
>  # include  /* defines bool but not _Bool */
> -# undef false
> -# undef true
>  #endif

Do you have a machine on which you tested this part? I mean, I wouldn't
have put in the #undefs if I hadn't seen gcc warnings otherwise.

> +   #if defined __xlc__ || __GNUC__
> +/* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
> +   reported by James Lemley on 2005-10-05; see

If this is meant to catch a bug in XLC, what's the purpose of the
__GNUC__ conditional?

I committed this part of the m4/stdbool.m4 patch, without the __GNUC__.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] proposed stdbool fixes for AIX, HP-UX, and now IRIX

[Bruno Haible]

Paul Eggert wrote:
> While looking into an old Bison bug report for IRIX

Where can I find the report, please?

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: getaddrinfo: finding gethostbyname in mingw32

[Bruno Haible]

Simon Josefsson wrote:
> Unless there is a simple concrete solution to this, I'm inclined to
> install the patch below and document that people using this module
> will have to call WSAStartup manually,

I don't know the simple concrete solution either :-), so I would do like
you say.

> +#define WINVER 0x0501

Can you explain the purpose of this line in a comment, please? For
maintainability.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] Re: portability fix for bison-1.75

[Bruno Haible]

Paul Eggert wrote:
>   (__strndup): Revert to K&R-style function dfns, the glibc style.

Huh? We know the problems of K&R-style function definitions: arguments
of type 'float', 'short' and 'char' are implicitly promoted, leading to
a clash with the function prototype. Empty argument lists allow calls
later in the same compilation unit with argument, if no '(void)'
protype was seen. - Wouldn't it be better to move the glibc source code
to ANSI C?

>   * lib/strnlen.c: Don't claim it's taken from glibc; it's not.

It was taken from glibc/string/strnlen.c in 2000 or 2001, but glibc has
diverged since then, moving the file to glibc/sysdeps/generic/strnlen.c
and now back to glibc/string/strnlen.c.

How about this additional patch?

*** modules/strnlen 9 Jan 2006 21:40:18 -   1.6
--- modules/strnlen 24 Jan 2006 19:42:27 -
***
*** 20,24 
  LGPL
  
  Maintainer:
! glibc
  
--- 20,24 
  LGPL
  
  Maintainer:
! all
  
*** config/srclist.txt  24 Jan 2006 14:06:47 -  1.113
--- config/srclist.txt  24 Jan 2006 19:42:27 -
***
*** 259,265 
  #$LIBCSRC/string/strcasecmp.c lib gpl
  #$LIBCSRC/string/strchrnul.c  lib gpl
  #$LIBCSRC/string/strerror.c   lib gpl
- #$LIBCSRC/string/strnlen.clib gpl
  #$LIBCSRC/sysdeps/posix/gettimeofday.clib gpl
  #$LIBCSRC/sysdeps/posix/rename.c  lib gpl
  #$LIBCSRC/sysdeps/unix/mkdir.clib gpl
--- 259,264 



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] gnulib/gnulib-tool shell quoting problem for Solaris /bin/sh

[Bruno Haible]

Mark Baushke wrote:

> Okay, I tried your 'set -x' that and it appears the error message
> happens just after the func_import () finishes executing.
> ...
> + echo   - invoke gl_INIT in ./configure.in.
>   - invoke gl_INIT in ./configure.in.
> + exit 0
> + -
> ../gnulib/gnulib-tool: -: not found

I'm trying this patch. Does it work for you?


2006-01-25  Bruno Haible  <[EMAIL PROTECTED]>

* gnulib-tool (func_import): Use "trap :" instead of "trap -" to get
rid of a trap command. For Solaris sh.
Reported by Mark D. Baushke <[EMAIL PROTECTED]>.

*** gnulib-tool 24 Jan 2006 19:18:45 -  1.104
--- gnulib-tool 25 Jan 2006 14:19:32 -
***
*** 1176,1182 
  func_add_or_update
done
rm -rf "$tmp"
!   trap - 0 1 2 3 15
  
# Command-line invocation printed in a comment in generated gnulib-cache.m4.
actioncmd="gnulib-tool --import"
--- 1176,1182 
  func_add_or_update
done
rm -rf "$tmp"
!   trap : 0 1 2 3 15
  
# Command-line invocation printed in a comment in generated gnulib-cache.m4.
actioncmd="gnulib-tool --import"



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

fts.c compilation error

[Bruno Haible]

A gnulib testdir with modules fts and quotearg fails to compile on IRIX 6.5
with CC="cc -O":

cc -O -DHAVE_CONFIG_H -I. -I. -I..  -g -c fts.c

"fts.c", line 244: error(1241): declaration may not appear after executable
  statement in block
size_t maxarglen = fts_maxarglen(argv);
^

1 error detected in the compilation of "fts.c".

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: proposed stdbool fixes for AIX, HP-UX, and now IRIX

[Bruno Haible]

Paul Eggert wrote:
> The output (when compiling Bison) contained oodles of "An enumerated
> type is mixed with another type" diagnostics, because the compiler
> didn't like mixing int values like 0 and 1 (which "false" and "true"
> evaluated to) with bool values.  There were so many diagnostics, and
> they were formatted weirdly enough, that it was hard to find the real
> diagnostics that were more important.
> ...
> Here is a public message that talks about a similar problem with the
> SGI compilers:
>
> http://lists.gnu.org/archive/html/bug-textutils/2002-02/msg00020.html

Thanks, I'm applying the patch below. It tacifies IRIX cc.

> The obvious solution is to stop using enum for bool values.

I don't know what you will propose, but
  - "enum" is fundamentally the right concept for this; "enum" in C was
introduced for exactly this kind of symbolic values,
  - Regarding the stdbool and stdint modules, I prefer an approach that
doesn't break unrelated platforms. We have already invested some effort
in these modules. I'm not interested in retesting it on platforms
from Linux libc5 to HP-UX 10 to BeOS.

Bruno


2006-01-25  Bruno Haible  <[EMAIL PROTECTED]>

* stdbool_.h (_Bool) [IRIX cc]: Define as 'signed char', to avoid
warnings.
Reported by Paul Eggert.

*** stdbool_.h  24 Jan 2006 22:00:13 -  1.8
--- stdbool_.h  25 Jan 2006 13:52:11 -
***
*** 90,97 
  enum { false = 0, true = 1 };
  #  endif
  # else
! #  if defined __SUNPRO_C && (__SUNPRO_C < 0x550 || __STDC__ == 1)
! /* Avoid stupid "warning: _Bool is a keyword in ISO C99".  */
  #   define _Bool signed char
  enum { false = 0, true = 1 };
  #  else
--- 90,100 
  enum { false = 0, true = 1 };
  #  endif
  # else
! #  if (defined __SUNPRO_C && (__SUNPRO_C < 0x550 || __STDC__ == 1)) || 
(defined __sgi && !defined __GNUC__)
! /* With SunPRO C, avoid stupid
!  "warning: _Bool is a keyword in ISO C99".
!With IRIX cc, avoid stupid
!  "warning(1185): enumerated type mixed with another type".  */
  #   define _Bool signed char
  enum { false = 0, true = 1 };
  #  else



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

bug in 'obstack' module

[Bruno Haible]

The obstack module does not compile on MacOS X:

Making all in lib
make  all-am
gcc -DHAVE_CONFIG_H -I. -I../../../megatestdir/obstack/lib -I.. -g -O2 -c 
../../../megatestdir/obstack/lib/exitfail.c
gcc -DHAVE_CONFIG_H -I. -I../../../megatestdir/obstack/lib -I.. -g -O2 -c 
../../../megatestdir/obstack/lib/obstack.c
../../../megatestdir/obstack/lib/obstack.c:69: error: parse error before 
"uintmax_t"
../../../megatestdir/obstack/lib/obstack.c:69: warning: no semicolon at end of 
struct or union
../../../megatestdir/obstack/lib/obstack.c:70: warning: use of `long double' 
type; its size may change in a future release
../../../megatestdir/obstack/lib/obstack.c:70: warning: (Long double usage is 
reported only once for each file.
../../../megatestdir/obstack/lib/obstack.c:70: warning: To disable this 
warning, use -Wno-long-double.)
../../../megatestdir/obstack/lib/obstack.c:72: error: parse error before '}' 
token
../../../megatestdir/obstack/lib/obstack.c:76: error: field `u' has incomplete 
type
../../../megatestdir/obstack/lib/obstack.c:83: error: enumerator value for 
`DEFAULT_ALIGNMENT' not integer constant
../../../megatestdir/obstack/lib/obstack.c:85: error: invalid application of 
`sizeof' to an incomplete type
make[4]: *** [obstack.o] Error 1
make[4]: Target `all-am' not remade because of errors.
make[3]: *** [all] Error 2

The config.h contains the following, related to uintmax_t:


/* Define if  exists, doesn't clash with , and
   declares uintmax_t. */
#define HAVE_INTTYPES_H_WITH_UINTMAX 1

/* Define if  exists, doesn't clash with , and declares
   uintmax_t. */ 
#define HAVE_STDINT_H_WITH_UINTMAX 1

/* Define if you have the 'uintmax_t' type in  or . */
#define HAVE_UINTMAX_T 1

/* Define to unsigned long or unsigned long long if  and
don't define. */
/* #undef uintmax_t */


The problem is that obstack.c uses HAVE_INTTYPES_H and HAVE_STDINT_H,
but these are not set by the autoconf macros. (Compare inttypes.m4
with inttypes_h.m4, and stdint.m4 with stdint_h.m4.)

Bruno




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

module 'fts-lgpl' not complete

[Bruno Haible]

Hi,

Building the module 'fts-lgpl' on Linux/glibc fails like this:

gcc -DHAVE_CONFIG_H -I. -I/packages/megatestdir/fts-lgpl/lib -I.. -g -O2 -c 
/packages/megatestdir/fts-lgpl/lib/fts.c
/packages/megatestdir/fts-lgpl/lib/fts.c:75:20: lstat.h: No such file or 
directory

The reason is that the 'lstat' module is GPL.

Jim, would you agree to put the 'lstat' module under LGPL if we cut its
dependency from the 'xalloc' module? Actually, using allocsa instead of
xmalloc will also speed it up. What do you think about these two alternative
patches?

Bruno


*** lstat.c 2005-09-21 13:08:21.0 +0200
--- lstat.c.1   2006-01-08 18:38:41.0 +0100
***
*** 1,6 
  /* Work around a bug of lstat on some systems
  
!Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free
 Software Foundation, Inc.
  
 This program is free software; you can redistribute it and/or modify
--- 1,6 
  /* Work around a bug of lstat on some systems
  
!Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 
Free
 Software Foundation, Inc.
  
 This program is free software; you can redistribute it and/or modify
***
*** 30,40 
  
  #include 
  #include 
  #include 
  #include 
  
  #include "stat-macros.h"
- #include "xalloc.h"
  
  /* lstat works differently on Linux and Solaris systems.  POSIX (see
 `pathname resolution' in the glossary) requires that programs like `ls'
--- 30,41 
  
  #include 
  #include 
+ #include 
  #include 
  #include 
  
+ #include "allocsa.h"
  #include "stat-macros.h"
  
  /* lstat works differently on Linux and Solaris systems.  POSIX (see
 `pathname resolution' in the glossary) requires that programs like `ls'
***
*** 65,77 
   Append a `.' to FILE and repeat the lstat call.  */
  
/* Add one for the `.' we'll append, and one more for the trailing NUL.  */
!   new_file = xmalloc (len + 1 + 1);
memcpy (new_file, file, len);
new_file[len] = '.';
new_file[len + 1] = 0;
  
lstat_result = lstat (new_file, sbuf);
!   free (new_file);
  
return lstat_result;
  }
--- 66,83 
   Append a `.' to FILE and repeat the lstat call.  */
  
/* Add one for the `.' we'll append, and one more for the trailing NUL.  */
!   new_file = allocsa (len + 1 + 1);
!   if (new_file == NULL)
! {
!   errno = ENOMEM;
!   return -1;
! }
memcpy (new_file, file, len);
new_file[len] = '.';
new_file[len + 1] = 0;
  
lstat_result = lstat (new_file, sbuf);
!   freesa (new_file);
  
return lstat_result;
  }
*** lstat.c 2005-09-21 13:08:21.0 +0200
--- lstat.c.2   2006-01-08 18:38:41.0 +0100
***
*** 1,6 
  /* Work around a bug of lstat on some systems
  
!Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free
 Software Foundation, Inc.
  
 This program is free software; you can redistribute it and/or modify
--- 1,6 
  /* Work around a bug of lstat on some systems
  
!Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 
Free
 Software Foundation, Inc.
  
 This program is free software; you can redistribute it and/or modify
***
*** 44,50 
 `lstat("symlink/.",sbuf)', but on Solaris it does not.
  
 If FILE has a trailing slash and specifies a symbolic link,
!then append a `.' to FILE and call lstat a second time.  */
  
  int
  rpl_lstat (const char *file, struct stat *sbuf)
--- 44,50 
 `lstat("symlink/.",sbuf)', but on Solaris it does not.
  
 If FILE has a trailing slash and specifies a symbolic link,
!then call stat instead.  */
  
  int
  rpl_lstat (const char *file, struct stat *sbuf)
***
*** 62,77 
  return lstat_result;
  
/* FILE refers to a symbolic link and the name ends with a slash.
!  Append a `.' to FILE and repeat the lstat call.  */
  
!   /* Add one for the `.' we'll append, and one more for the trailing NUL.  */
!   new_file = xmalloc (len + 1 + 1);
!   memcpy (new_file, file, len);
!   new_file[len] = '.';
!   new_file[len + 1] = 0;
! 
!   lstat_result = lstat (new_file, sbuf);
!   free (new_file);
! 
!   return lstat_result;
  }
--- 62,68 
  return lstat_result;
  
/* FILE refers to a symbolic link and the name ends with a slash.
!  Call stat() to get info about the link's destination.  */
  
!   return stat (file, sbuf);
  }




___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] gnulib/gnulib-tool shell quoting problem for Solaris /bin/sh

[Bruno Haible]

Eric Blake wrote:
> Remember this thread, which patched the same bug in install-sh?
> http://lists.gnu.org/archive/html/bug-autoconf/2005-11/msg0.html

Thanks for this pointer. It is regrettable that no doc was added to
the autoconf manual about this pitfall.

> Wouldn't "trap ''" be better than "trap :"?  trap '' is documented
> as restoring default behavior of the signal

Huh? That's not what you wrote
http://lists.gnu.org/archive/html/bug-autoconf/2005-11/msg6.html,
and it's not what is written in POSIX
http://www.opengroup.org/susv3/utilities/trap.html.

POSIX says that "trap ''" makes the shell "ignore each specified condition
if it arises". That means, if the user presses Ctrl-C, the shell will
continue to run. That's not what I want here. I just wish the Ctrl-C
to trigger no additional commands, and "trap :" looks right for doing this.

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: module 'fts-lgpl' not complete

[Bruno Haible]

Hi Jim,

> Regarding the second patch, I see no explanation for why it
> makes such a fundamental change (not appending `.'?).

Actually the end of that function was a bit incomplete. It should probably
look like this:

/* FILE refers to a symbolic link and the name ends with a slash.
   Call stat() to get info about the link's destination.  */
  
lstat_result = stat (file, sbuf);
if (lstat_result >= 0 && !S_ISDIR (sbuf->st_mode))
  {
errno = EINVAL;
return -1;
  }
else
  return lstat_result;

The idea is that if FILE is a symlink and ends in '/', we want to inspect
the inode of the target directory of the link, i.e. follow the symlink
chain. lstat(concat(FILE,".")) does this, but stat(FILE) does this as well,
and needs no intermediate memory allocation. Or am I overlooking something
obvious?

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: [bug-gnulib] gnulib/gnulib-tool shell quoting problem for Solaris /bin/sh

[Bruno Haible]

Mark D. Baushke wrote:
> > I'm trying this patch. Does it work for you?
>
> Yes.

Thanks. I've committed the fix.

> |   If argument is  absent,  all
> |   trap(s) n are reset to their original values.

This explains how "trap" without arguments works, not how "trap 0 1 2 3 15"
works, no?

Bruno



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: gnulib/gnulib-tool shell quoting problem for Solaris /bin/sh

[Bruno Haible]

Paul Eggert wrote:
> The difference can be seen with this script:
>
> trap : 2
> sleep 5
> sleep 10
>
> If you execute this with "bash -x", and interrupt the "sleep 5" with
> Control-C, you'll see that the "sleep 10" is executed with "trap :",
> whereas it would not be executed with "trap -".

Oh, you are right, thanks. I misunderstood how 'trap' works.

> How about if you replace this:
>
>   trap : 0 1 2 3 15
>
> with this?
>
>   trap '' 0
>   trap '(exit $?); exit $?' 1 2 13 15

This works as desired, thanks. The following works as well:

  trap '' 0
  trap 'exit $?' 1 2 13 15

Tested with both bash and zsh. (The confusion about the interpretation
of $? within trap between bash and zsh/Solaris sh applies only to the 0
signal. For signal 2, $? is 130 in all cases.)

I committed the appended patch.

Bruno


*** gnulib-tool 25 Jan 2006 14:20:06 -  1.105
--- gnulib-tool 26 Jan 2006 12:51:07 -
***
*** 1176,1182 
  func_add_or_update
done
rm -rf "$tmp"
!   trap : 0 1 2 3 15
  
# Command-line invocation printed in a comment in generated gnulib-cache.m4.
actioncmd="gnulib-tool --import"
--- 1176,1188 
  func_add_or_update
done
rm -rf "$tmp"
!   # Undo the effect of the previous 'trap' command. Some shellology:
!   # We cannot use "trap - 0 1 2 3 15", because Solaris sh would attempt to
!   # execute the command "-". "trap '' ..." is fine only for signal 0 (= normal
!   # exit); for the others we need to call 'exit' explicitly. The value of $? 
is
!   # 128 + signal number and is set before the trap-registered command is run.
!   trap '' 0
!   trap 'exit $?' 1 2 3 15
  
# Command-line invocation printed in a comment in generated gnulib-cache.m4.
actioncmd="gnulib-tool --import"



___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

Re: proposed stdbool fixes for AIX, HP-UX, and now IRIX

[Bruno Haible]

Paul Eggert wrote:
> How about this change?  It reflects what's currently installed into
> coreutils (I merged your changes).  I've tested this with GCC 2.95 and
> it works the way you like there.

Thanks,

> The basic idea is to make bool an
> enum type when using GCC, but to fall back on signed char
> otherwise.  This simplifies stdbool_.h and makes it more conservative.
> The ChangeLog entry has the most-complicated conditional I've ever
> written inside [brackets], but that complication is there precisely
> because the proposed patch removes it from the code.

Thanks, Since I don't mind about debuggability with non-gcc compilers,
I've applied your patch regarding the non-gcc compilers, with
slightly different comments.

Your patch also modifies the behaviour when gcc is used and it has _Bool
but  as a whole doesn't work. We haven't seen a bug in this area,
and I remember that for several gcc versions, the problems were in the
stdbool.h file, not in the built-in type. So I propose to continue using
_Bool in that case, unlike your patch.

The ChangeLog conditional became slightly less complicated due to this.

I applied the appended patches.

Bruno

*** lib/stdbool_.h  25 Jan 2006 13:55:43 -  1.9
--- lib/stdbool_.h  26 Jan 2006 13:31:49 -  1.10
***
*** 78,103 
  typedef bool _Bool;
  # endif
  #else
! # if @HAVE__BOOL@
! #  if defined __HP_cc || defined __xlc__
! /* Some HP-UX cc and AIX IBM C compiler versions have compiler bugs when
!the built-in _Bool type is used.  See
!  http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
!  http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html
!  http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
!Override it.  */
! #   define _Bool signed char
  enum { false = 0, true = 1 };
- #  endif
  # else
! #  if (defined __SUNPRO_C && (__SUNPRO_C < 0x550 || __STDC__ == 1)) || 
(defined __sgi && !defined __GNUC__)
! /* With SunPRO C, avoid stupid
!  "warning: _Bool is a keyword in ISO C99".
!With IRIX cc, avoid stupid
!  "warning(1185): enumerated type mixed with another type".  */
! #   define _Bool signed char
! enum { false = 0, true = 1 };
! #  else
  typedef enum { _Bool_must_promote_to_int = -1, false = 0, true = 1 } _Bool;
  #  endif
  # endif
--- 78,106 
  typedef bool _Bool;
  # endif
  #else
! # if !defined __GNUC__
!/* If @HAVE__BOOL@:
! Some HP-UX cc and AIX IBM C compiler versions have compiler bugs when
! the built-in _Bool type is used.  See
!   http://gcc.gnu.org/ml/gcc-patches/2003-12/msg02303.html
!   
http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00161.html
!   
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
! Similar bugs are likely with other compilers as well; this file
! wouldn't be used if  was working.
! So we override the _Bool type.
!   If [EMAIL PROTECTED]@:
! Need to define _Bool ourselves. As 'signed char' or as an enum type?
! Use of a typedef, with SunPRO C, leads to a stupid
!   "warning: _Bool is a keyword in ISO C99".
! Use of an enum type, with IRIX cc, leads to a stupid
!   "warning(1185): enumerated type mixed with another type".
! The only benefit of the enum type, debuggability, is not important
! with these compilers.  So use 'signed char' and no typedef.  */
! #  define _Bool signed char
  enum { false = 0, true = 1 };
  # else
!/* With this compiler, trust the _Bool type if the compiler has it.  */
! #  if [EMAIL PROTECTED]@
  typedef enum { _Bool_must_promote_to_int = -1, false = 0, true = 1 } _Bool;
  #  endif
  # endif
*** m4/stdbool.m4   24 Jan 2006 22:05:28 -  1.9
--- m4/stdbool.m4   26 Jan 2006 13:32:38 -  1.10
***
*** 74,80 
  _Bool n[m];
  char o[sizeof n == m * sizeof n[0] ? 1 : -1];
  char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
! #if defined __xlc__
   /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
  reported by James Lemley on 2005-10-05; see
  
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
--- 74,80 
  _Bool n[m];
  char o[sizeof n == m * sizeof n[0] ? 1 : -1];
  char p[-1 - (_Bool) 0 < 0 && -1 - (bool) 0 < 0 ? 1 : -1];
! #if defined __xlc__ || defined __GNUC__
   /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
  reported by James Lemley on 2005-10-05; see
  
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
***
*** 86,92 
  Let us hope that IBM fixes the xlc bug, and also adds
  support for this kind of constant expression.  In the
  meantime, this test will reject xlc, which is OK, since
! our stdbo