date:20060111

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

2006-01-11 Thread 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

2006-01-11 Thread 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

2006-01-11 Thread 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

2006-01-11 Thread 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

2006-01-11 Thread 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

2006-01-11 Thread 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

2006-01-11 Thread 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

2006-01-11 Thread 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

2006-01-11 Thread 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

2006-01-11 Thread 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

2006-01-11 Thread 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

2006-01-11 Thread Ralf Wildenhues

Hi Bruno,

* Bruno Haible wrote on Wed, Jan 11, 2006 at 01:48:02PM CET:

> *** 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"

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.

Cheers,
Ralf


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

Re: autoreconf is recursive

2006-01-11 Thread 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

stdint.h buglet

2006-01-11 Thread Simon Josefsson


Installed.   2006-01-11  Simon Josefsson  <[EMAIL PROTECTED]>

* stdint_.h (SIZE_MAX): Add missing (.

--- stdint_.h   09 Jan 2006 14:49:23 +0100  1.10
+++ stdint_.h   11 Jan 2006 18:11:10 +0100  
@@ -245,7 +245,7 @@
#define SIG_ATOMIC_MAX 127

#ifndef SIZE_MAX /* SIZE_MAX may also be defined in config.h. */
-# define SIZE_MAX (size_t)~(size_t)0)
+# define SIZE_MAX ((size_t)~(size_t)0)
#endif

/* wchar_t limits already defined in .  */


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

Re: Separate csharpcomp.sh, and a license problem

2006-01-11 Thread 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: Separate csharpcomp.sh, and a license problem

2006-01-11 Thread Simon Josefsson

Bruno Haible <[EMAIL PROTECTED]> writes:

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

Works fine, thanks!

However, I'm wondering whether:

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.  How about changing it to:

AC_CONFIG_FILES([build-aux/csharpcomp.sh])

?

Same for javacomp-script, I assume.

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

Re: autoreconf is recursive

2006-01-11 Thread Simon Josefsson

Bruno Haible <[EMAIL PROTECTED]> writes:

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

Reverting is ok by me, I don't think the change was made to fix any
particular problem.  It was a cleanup.

I think this should be considered a autoreconf bug and reported
though.  Is it really safe to avoid to regenerate in sub-directories?
If so, perhaps autoreconf should have a --no-recursion or similar?

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

Re: warning in 'base64' module

2006-01-11 Thread Simon Josefsson

Bruno Haible <[EMAIL PROTECTED]> writes:

> 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

Caused by:

static const signed char b64[0x100] = {
...
bool
isbase64 (char ch)
{
  return to_uchar (ch) <= 255 && 0 <= b64[to_uchar (ch)];
}

mentioned in:

http://article.gmane.org/gmane.comp.lib.gnulib.bugs/2694/match=base64+comparison+true+limited+range+data+type

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?


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

Re: warning in 'base64' module

2006-01-11 Thread Ralf Wildenhues

* Bruno Haible wrote on Wed, Jan 11, 2006 at 01:56:51PM CET:
> 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

You could just ignore the warning, and be happy that on your system
CHAR_BIT=8.

Cheers,
Ralf


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

Re: autoreconf is recursive

2006-01-11 Thread Ralf Wildenhues

* Bruno Haible wrote on Wed, Jan 11, 2006 at 05:20:48PM CET:
> 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?

Yes.  Thank you.

Cheers,
Ralf


___
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

2006-01-11 Thread Ralf Wildenhues

* Bruno Haible wrote on Wed, Jan 11, 2006 at 01:44:27PM CET:
> 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:

Erm, yes.  Similarly, `-zignore' is linker dependent.  And if I know
anything about how autotools-using build systems expect link flags and
libraries, then you're not supposed to put `-lrt' in LDFLAGS, but in
LIBS.

Furthermore, the test looks completely bogus to me, testing a basically
empty program: how is that going to *reliably* record the need of librt
for a real program?

Am I missing something when suggesting AC_SEARCH_LIBS?  I see that the
point of this module may be that several users of a single libgnulib
exist, and only some may *need* `-lrt'.  Right?  Well, why doesn't
gnulib allow to separate LDADD per module then, as a refinement?
Something like:
  module foo needs LIBS=... LDFLAGS=..
  ..
  module bar needs module foo

Topological sort solves the ordering problem.  And yes, please make it
so that you don't break static linking as done with lib-link.

If instead you admit defeat, then:
- without libtool, you could go through the resulting link line and
  eliminate libraries one by one (given that *the order was good*),
  as done for example in the VIM source.  Slow, but at least reliable.
- with libtool, you're out of luck without severe hacks
  (i.e., file a bug report requesting an enhancement, please).

Cheers,
Ralf

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

Re: warning in 'base64' module

2006-01-11 Thread 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: [bug-gnulib] new module lib-ignore; new section build_lib in MODULES.html

2006-01-11 Thread Paul Eggert

Bruno Haible <[EMAIL PROTECTED]> writes:

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

That's what leads to the problem here, but the problem can occur even
if we don't build a libgnulib.  For example, a package might not need
any gnulib .o files at all, but it still might invoke something like
gl_CLOCK_TIME, which merely sets LIB_CLOCK_GETTIME=-lrt and defines
HAVE_CLOCK_GETTIME.  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.

This sort of cataloging is error-prone and a pain to maintain.  It
should be automated, and -zignore does the automation.  (I don't know
why -zignore is not the default; but it isn't and we have to deal with
it.)

> 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

Now that you mention it, there's also 'otool -L' on Mac OS X.

However, does the problem occur with the linkers used on AIX, IRIX,
HP-UX, OSF/1, and Tru64?  If not, then I'm not sure it's worth trying
all the possibilities.  But if so, I suppose we could install a
further patch that looks something like the following.  But this
raises Ralf Wildenhues's point: do these other linkers need some other
option, one that isn't spelled "-zignore"?

--- lib-ignore.m4.~1.1.~2006-01-09 10:42:51.0 -0800
+++ lib-ignore.m4   2006-01-11 10:08:27.0 -0800
@@ -13,21 +13,29 @@ AC_DEFUN([gl_IGNORE_UNUSED_LIBRARIES],
 [gl_cv_ignore_unused_libraries],
 [gl_cv_ignore_unused_libraries=none
  AC_LINK_IFELSE([AC_LANG_PROGRAM()],
-   [gl_ldd_output0=`(ldd conftest$ac_exeext) 2>/dev/null` ||
- gl_ldd_output0=])
+   [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])
  if test "$gl_ldd_output0"; then
gl_saved_ldflags=$LDFLAGS
gl_saved_libs=$LIBS
LIBS="$LIBS -lm"
AC_LINK_IFELSE([AC_LANG_PROGRAM()],
-[gl_ldd_output1=`(ldd conftest$ac_exeext) 2>/dev/null` ||
+[gl_ldd_output1=`($gl_ldd conftest$ac_exeext) 2>/dev/null` ||
gl_ldd_output1=])
if test "$gl_ldd_output1" && test "$gl_ldd_output0" != "$gl_ldd_output1"
then
 for gl_flags in '-Xlinker -zignore' '-zignore'; do
   LDFLAGS="$gl_flags $LDFLAGS"
   AC_LINK_IFELSE([AC_LANG_PROGRAM()],
-[if gl_ldd_output2=`(ldd conftest$ac_exeext) 2>/dev/null` &&
+[if gl_ldd_output2=`($gl_ldd conftest$ac_exeext) 2>/dev/null` &&
 test "$gl_ldd_output0" = "$gl_ldd_output2"; then
gl_cv_ignore_unused_libraries=$gl_flags
  fi])

___
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

2006-01-11 Thread Paul Eggert

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> Similarly, `-zignore' is linker dependent.

Yes.  If some linkers need some other option to do that, we'll need to
add it to lib-ignore.m4.  But in the meantime the existing code should
produce working executables, even with those linkers, since it doesn't
use -zignore unless that makes a difference in the ldd output.

>  And if I know anything about how autotools-using build systems
> expect link flags and libraries, then you're not supposed to put
> `-lrt' in LDFLAGS, but in LIBS.

Yes, that's what the lib-ignore code does; it puts -lm into LIBS in
order to test -zignore.

> Furthermore, the test looks completely bogus to me, testing a basically
> empty program: how is that going to *reliably* record the need of librt
> for a real program?

It works reliably on Solaris, for -lm.  It also works on Debian
GNU/Linux, in that it discovers that -zignore isn't needed there.  If
it breaks on some other platform then I'd like to know about it, and
I'd like to fix it.

> why doesn't gnulib allow to separate LDADD per module then, as a
> refinement?

gnulib already does that, with variables like LIB_CLOCK_GETTIME.  But
the problem is maintaining the list of LDADDs.  At the end of this
message is an extract from coreutils/src/Makefile.am.  This list is
maintained by hand, and it's error-prone.  For example, with coreutils
5.93 "ldd who" has the following output on my Solaris 8 host (64-bit):

libnsl.so.1 =>   /usr/lib/64/libnsl.so.1
libsocket.so.1 =>/usr/lib/64/libsocket.so.1
libc.so.1 => /usr/lib/64/libc.so.1
libdl.so.1 =>/usr/lib/64/libdl.so.1
libmp.so.2 =>/usr/lib/64/libmp.so.2
/usr/platform/SUNW,Ultra-4/lib/sparcv9/libc_psr.so.1

I think only libc and libdl are needed; the rest aren't.  This could
be worked around by further editing the Makefile gorp below, but it's
much better to have the linker figure it out.

-

# Sometimes, the expansion of $(LIBINTL) includes -lc which may
# include modules defining variables like `optind', so libcoreutils.a
# must precede $(LIBINTL) in order to ensure we use GNU getopt.
# But libcoreutils.a must also follow $(LIBINTL), since libintl uses
# replacement functions defined in libcoreutils.a.
LDADD = ../lib/libcoreutils.a $(LIBINTL) ../lib/libcoreutils.a

# for eaccess in lib/euidaccess.c.
cp_LDADD = $(LDADD) $(LIB_EACCESS)
ginstall_LDADD = $(LDADD) $(LIB_EACCESS)
mv_LDADD = $(LDADD) $(LIB_EACCESS)
pathchk_LDADD = $(LDADD) $(LIB_EACCESS)
rm_LDADD = $(LDADD) $(LIB_EACCESS)
test_LDADD = $(LDADD) $(LIB_EACCESS)
# This is for the '[' program.  Automake transliterates '[' to '_'.
__LDADD = $(LDADD) $(LIB_EACCESS)

# for clock_gettime and fdatasync
dd_LDADD = $(LDADD) $(LIB_GETHRXTIME) $(LIB_FDATASYNC)
dir_LDADD = $(LDADD) $(LIB_CLOCK_GETTIME)
ls_LDADD = $(LDADD) $(LIB_CLOCK_GETTIME)
pr_LDADD = $(LDADD) $(LIB_CLOCK_GETTIME)
shred_LDADD = $(LDADD) $(LIB_GETHRXTIME) $(LIB_FDATASYNC)
vdir_LDADD = $(LDADD) $(LIB_CLOCK_GETTIME)

## If necessary, add -lm to resolve use of pow in lib/strtod.c.
sort_LDADD = $(LDADD) $(POW_LIB) $(LIB_GETHRXTIME)

# for get_date and gettime
date_LDADD = $(LDADD) $(LIB_CLOCK_GETTIME)
touch_LDADD = $(LDADD) $(LIB_CLOCK_GETTIME)

# If necessary, add -lm to resolve use of pow in lib/strtod.c.
# If necessary, add -liconv to resolve use of iconv in lib/unicodeio.c.
printf_LDADD = $(LDADD) $(POW_LIB) $(LIBICONV)

# If necessary, add -lm to resolve use of floor, rint, modf.
seq_LDADD = $(LDADD) $(SEQ_LIBM)

# If necessary, add libraries to resolve the `pow' reference in lib/strtod.c
# and the `nanosleep' reference in lib/xnanosleep.c.
nanosec_libs = $(LDADD) $(POW_LIB) $(LIB_NANOSLEEP)

sleep_LDADD = $(nanosec_libs)
tail_LDADD = $(nanosec_libs)

uptime_LDADD = $(LDADD) $(GETLOADAVG_LIBS)

su_LDADD = $(LDADD) $(LIB_CRYPT)

dir_LDADD += $(LIB_ACL)
ls_LDADD += $(LIB_ACL)
vdir_LDADD += $(LIB_ACL)
cp_LDADD += $(LIB_ACL)
mv_LDADD += $(LIB_ACL)
ginstall_LDADD += $(LIB_ACL)

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

Re: getprogname

2006-01-11 Thread Paul Eggert

Bruno Haible <[EMAIL PROTECTED]> writes:

> It is not so easy.
> ...
>   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().
> ...
> My vote is therefore for d).

Me too.  Thanks for investigating all this.


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

Re: autoreconf is recursive

2006-01-11 Thread 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

2006-01-11 Thread 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

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

2006-01-11 Thread Ralf Wildenhues

* Paul Eggert wrote on Wed, Jan 11, 2006 at 07:28:55PM CET:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> >  And if I know anything about how autotools-using build systems
> > expect link flags and libraries, then you're not supposed to put
> > `-lrt' in LDFLAGS, but in LIBS.
> 
> Yes, that's what the lib-ignore code does; it puts -lm into LIBS in
> order to test -zignore.

Argh.  I misread the code, and badly at that.  Please take my humble
apologies, some of my resulting conclusions in my previous message were
completely nonsensical.

> > Furthermore, the test looks completely bogus to me, testing a basically
> > empty program: how is that going to *reliably* record the need of librt
> > for a real program?
> 
> It works reliably on Solaris, for -lm.  It also works on Debian
> GNU/Linux, in that it discovers that -zignore isn't needed there.  If
> it breaks on some other platform then I'd like to know about it, and
> I'd like to fix it.

OK.  I don't know of any at the moment.

On the contrary, I'd see some usefulness for a similar macro in libtool.

Since classically I'd propose that a macro that would be useful for
different packages belong into Autoconf, but it has become style to put
stuff in gnulib instead, and never release that, I'm asking myself ATM
if that is just another sign of too few Autoconf releases.  Oh well.

> > why doesn't gnulib allow to separate LDADD per module then, as a
> > refinement?
> 
> gnulib already does that, with variables like LIB_CLOCK_GETTIME.  But
> the problem is maintaining the list of LDADDs.  At the end of this
> message is an extract from coreutils/src/Makefile.am.  This list is
> maintained by hand, and it's error-prone.

I agree.  The trade-off then is: ignore the too-many unused libs on
systems with lesser capable/unsupported linkers, against error-prone
maintenance-intensive makefiles.

Note that use of this macro won't save you from using AC_SEARCH_LIBS.

Cheers,
Ralf

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

Re: warning in 'base64' module

2006-01-11 Thread Paul Eggert

Simon Josefsson <[EMAIL PROTECTED]> writes:

> Is there a clean fix?

How about something like this?

#if UCHAR_MAX == 255
# define uchar_in_range(c) true
#else
# define uchar_in_range(c) ((c) <= 255)
#endif

and then use uchar_in_range in the rest of your code.


___
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

2006-01-11 Thread Paul Eggert

Bruno Haible <[EMAIL PROTECTED]> writes:

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

No, because the link will still work even if we link to all the
libraries in question.  The programs will still run, even if they
start up a bit slower.

If we run into a linker that needs some option other than -zignore
then we can use that option.

If we run into a linker that does not support the -zignore
functionality, then we can worry about it then, but perhaps the rarity
of this loss in performance won't be worth the hassle in writing a
linker wrapper that figures this stuff out at link-time.

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

Thanks, I'll take that into account.

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

Yes, that's possible.  If this happens, the current implementation
will append -zignore even though -zignore didn't really help.
However, the program will still link, so this won't break anything.

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

sha1, md5 changes

2006-01-11 Thread Paul Eggert

I installed the following to sync with changes I'm about to install
into coreutils.  Basically this removes some unnecessary differences
between sha1 and md5, mostly by moving Bruno's recent md5 improvements
into sha1.

2006-01-11  Paul Eggert  <[EMAIL PROTECTED]>

* md5.c: Fix commentary typos.
(alignof, UNALIGNED_P): No need for a GCC-specific version.
* md5.h (__attribute__): Remove; unused.
* sha1.c: Fix commentary to match md5 better.
* sha1.h (struct sha1_ctx): Use a word buffer, not a byte buffer,
so that we don't need to worry about alignment.  All uses changed.
This merges the 2005-10-28 md5 change into sha1.

2006-01-11  Jim Meyering  <[EMAIL PROTECTED]>

* md5.c (OP): Fix spacing.

Index: lib/md5.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/md5.c,v
retrieving revision 1.22
retrieving revision 1.23
diff -p -u -r1.22 -r1.23
--- lib/md5.c   28 Oct 2005 12:15:56 -  1.22
+++ lib/md5.c   12 Jan 2006 05:40:19 -  1.23
@@ -1,6 +1,6 @@
 /* Functions to compute MD5 message digest of files or memory blocks.
according to the definition of MD5 in RFC 1321 from April 1992.
-   Copyright (C) 1995,1996,1997,1999,2000,2001,2005
+   Copyright (C) 1995,1996,1997,1999,2000,2001,2005,2006
Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
@@ -86,7 +86,7 @@ md5_init_ctx (struct md5_ctx *ctx)
must be in little endian byte order.
 
IMPORTANT: On some systems it is required that RESBUF is correctly
-   aligned for a 32 bits value.  */
+   aligned for a 32-bit value.  */
 void *
 md5_read_ctx (const struct md5_ctx *ctx, void *resbuf)
 {
@@ -102,7 +102,7 @@ md5_read_ctx (const struct md5_ctx *ctx,
prolog according to the standard and write the result to RESBUF.
 
IMPORTANT: On some systems it is required that RESBUF is correctly
-   aligned for a 32 bits value.  */
+   aligned for a 32-bit value.  */
 void *
 md5_finish_ctx (struct md5_ctx *ctx, void *resbuf)
 {
@@ -245,14 +245,8 @@ md5_process_bytes (const void *buffer, s
   if (len >= 64)
 {
 #if !_STRING_ARCH_unaligned
-/* To check alignment gcc has an appropriate operator.  Other
-   compilers don't.  */
-# if __GNUC__ >= 2
-#  define UNALIGNED_P(p) (((uintptr_t) p) % __alignof__ (uint32_t) != 0)
-# else
-#  define alignof(type) offsetof (struct { char c; type x; }, x)
-#  define UNALIGNED_P(p) (((size_t) p) % alignof (uint32_t) != 0)
-# endif
+# define alignof(type) offsetof (struct { char c; type x; }, x)
+# define UNALIGNED_P(p) (((size_t) p) % alignof (uint32_t) != 0)
   if (UNALIGNED_P (buffer))
while (len > 64)
  {
@@ -382,7 +376,7 @@ md5_process_block (const void *buffer, s
  argument specifying the function to use.  */
 #undef OP
 #define OP(f, a, b, c, d, k, s, T) \
-  do   \
+  do   \
{   \
  a += f (b, c, d) + correct_words[k] + T;  \
  CYCLIC (a, s);\
Index: lib/md5.h
===
RCS file: /cvsroot/gnulib/gnulib/lib/md5.h,v
retrieving revision 1.20
retrieving revision 1.21
diff -p -u -r1.20 -r1.21
--- lib/md5.h   28 Oct 2005 12:15:56 -  1.20
+++ lib/md5.h   12 Jan 2006 05:40:19 -  1.21
@@ -1,6 +1,6 @@
 /* Declaration of functions and data types used for MD5 sum computing
library functions.
-   Copyright (C) 1995-1997,1999,2000,2001,2004,2005
+   Copyright (C) 1995-1997,1999,2000,2001,2004,2005,2006
   Free Software Foundation, Inc.
This file is part of the GNU C Library.
 
@@ -44,12 +44,6 @@
 # endif
 #endif
 
-#ifndef __attribute__
-# if ! __GNUC_PREREQ (2,8) || __STRICT_ANSI__
-#  define __attribute__(x)
-# endif
-#endif
-
 #ifndef _LIBC
 # define __md5_buffer md5_buffer
 # define __md5_finish_ctx md5_finish_ctx
Index: lib/sha1.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/sha1.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -p -u -r1.6 -r1.7
--- lib/sha1.c  10 Jan 2006 21:31:01 -  1.6
+++ lib/sha1.c  12 Jan 2006 05:40:19 -  1.7
@@ -1,7 +1,8 @@
 /* sha1.c - Functions to compute SHA1 message digest of files or
memory blocks according to the NIST specification FIPS-180-1.
 
-   Copyright (C) 2000, 2001, 2003, 2004, 2005 Free Software Foundation, Inc.
+   Copyright (C) 2000, 2001, 2003, 2004, 2005, 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 the
@@ -35,9 +36,6 @@
 # include "unlocked-io.h"
 #endif
 
-/* SWAP does

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

gl_LOCK vs. gl_ARGP ordering

warnings in 'argp' module

warnings in 'filenamecat' module

Re: Separate csharpcomp.sh, and a license problem

autoreconf is recursive

bug in mathl module

bug in gc-des module

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

warning in 'base64' module

Re: getprogname

Re: autoreconf is recursive

Re: autoreconf is recursive

stdint.h buglet

Re: Separate csharpcomp.sh, and a license problem

Re: Separate csharpcomp.sh, and a license problem

Re: autoreconf is recursive

Re: warning in 'base64' module

Re: warning in 'base64' module

Re: autoreconf is recursive

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

Re: warning in 'base64' module

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

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

Re: getprogname

Re: autoreconf is recursive

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

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

Re: warning in 'base64' module

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

sha1, md5 changes

31 matches

Site Navigation

Mail list logo

Footer information