==> "rb" == Rob Browning <[EMAIL PROTECTED]> writes:
rb> [EMAIL PROTECTED] writes:
>> Another solution (probably covered here) is to fill in the
>> LIBRARY_PATH search path:
>>
rb> Could you explain this a little further? By LIBRARY_PATH here
rb> do you mean LD_LIBRARY_PATH (at least for Linux)?
rb> If so, I'm not sure this will help since the relink step
rb> explicitly mentions -L/usr/lib -lfoo when I'm actually
rb> installing into ./tmp via "make DESTDIR=`pwd`/tmp install",
rb> and of course, foo's in pwd/tmp, not /usr/lib yet.
rb> What I need is for the relink step to link against the build
rb> tree libfoo (or more likely the DESTDIR libfoo) and not worry
rb> about the fact that the library's eventually going to be in
rb> /usr/lib...
The LIBRARY_PATH variable is what I meant.
The LD_LIBRARY_PATH variable is for ELF systems to find shared
libraries at run-time. The LIBRARY_PATH variable, on the other hand,
is a gcc setting that lets it find libraries at link-time. It's a
colon-separated path that fills in a bunch of '-L' options. Other
linkers have similar extensions -- LPATH, LOPTS, etc.
If we fixup all of the .la files (such as by configuring to $DESTDIR),
then they'll be broken when the shared libraries are installed to
their final locations -- the $exec_prefix setting in the .la file
drives the -rpath switches during the relink.
What's desired here is to leave the .la files unchanged, but to add
some more link-time link paths (via -L switches). If you don't want
to hack your Makefiles, you can trick the build process by exporting a
custom LIBRARY_PATH setting to the make process. One could envision a
DESTDIR-aware libtool that would do this automatically.
I've used this trick successfully in building rpm's containing
multiple, interdependent shared libraries. The spec file cooks up a
custom LIBRARY_PATH setting before invoking 'make DESTDIR=foo
install'. The name of the game in spec file writing is to minimize
the patch set required to build the package, so Makefile hackery is
discouraged.
- C
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
