Hello,
Peter O'Gorman wrote:
> > libtool unfortunately wants to write into the .libs directory
> > during "make install".
>
> I vaguely recall a requst fairly recently on the libool list to relink in a
> tmpdir, I guess I'd better go look into that. :/
Absolutely. There are three major grips that I have with libtool 1.x, that
could be solved by naming files differently than now:
1) "make install" relinking: it not only writes into .libs, it also
temporarily replaces the libraries in .libs. IMO one should better
relink in the destination directory (because this one is guaranteed to
be writable) or in a temp dir under the the destination directory.
2) An executable in .libs an "lt-" prefix, that I must remove when I want
good --help output in the build directory. (Which I need for using
"help2man".) So far I'm using this code.
/* Set program_name, based on argv[0]. */
void
set_program_name (const char *argv0)
{
/* libtool creates a temporary executable whose name is sometimes prefixed
with "lt-" (depends on the platform). It also makes argv[0] absolute.
Remove this "<dirname>/.libs/" or "<dirname>/.libs/lt-" prefix here. */
const char *slash;
const char *base;
slash = strrchr (argv0, '/');
base = (slash != NULL ? slash + 1 : argv0);
if (base - argv0 >= 7 && memcmp (base - 7, "/.libs/", 7) == 0)
argv0 = base;
if (strncmp (base, "lt-", 3) == 0)
argv0 = base + 3;
program_name = argv0;
}
3) Instead of an executable itself I find a shell script. So that I cannot
use "gdb foo" but rather must do "libtool gdb foo". Which I most of the
time don't do, because setting breakpoints in shared libraries often is
a pain. Instead "make distclean; ./configure --disable-shared", because
then debugging with gdb is a lot easier.
Bruno
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
