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