Re: new module 'ldd'

2006-01-12 Thread Bob Friesenhahn
On Thu, 12 Jan 2006, Bruno Haible wrote: 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 expens

Re: a real fts.c bug + fix

2006-01-12 Thread Paul Eggert
Jim Meyering <[EMAIL PROTECTED]> writes: > If any of you know of a system with file name resolution code that > doesn't fail for a chain of 400 symlinks, or for which you get a > different diagnostic than `Too many levels of symbolic links' (ELOOP), > please provide details. On Solaris 8 through

Re: new module 'ldd'

2006-01-12 Thread 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 co

Re: new module 'ldd'

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

Re: a real fts.c bug + fix

2006-01-12 Thread Jim Meyering
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> If any of you know of a system with file name resolution code that >> doesn't fail for a chain of 400 symlinks, or for which you get a >> different diagnostic than `Too many levels of symbolic links' (ELOOP), >>

Re: new module 'ldd'

2006-01-12 Thread 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 packag

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

2006-01-12 Thread 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/nu

new module 'ldd'

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

a real fts.c bug + fix

2006-01-12 Thread Jim Meyering
I discovered a long-standing bug in fts.c yesterday: 2006-01-11 Jim Meyering <[EMAIL PROTECTED]> * fts.c (fts_stat): When following a symlink-to-directory, don't necessarily interpret stat-fails+lstat-succeeds as indicating a dangling symlink. That can also happen at le

Re: warning in 'base64' module

2006-01-12 Thread Simon Josefsson
Paul Eggert <[EMAIL PROTECTED]> writes: > 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