[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
