Behdad Esfahbod wrote:
On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:
I think that all above is out of libtool scope.
It's is exceptional project specific (lets skip cross-compilation
environment) and is subject of project regression test suite.
The project is responsible to set appropriate test environment before
to run regression test.
Please let me know when I don't understand request properly.
It's not about regression testing at all. It's about making binaries in
uninstalled builds work. For example, many GNOME applications need to
load their UI from XML files. If you build and not install them and try
to run from the build dir, not surprisingly, the XML file is not found
at destination, and the program will fail to start. With my proposed
additions, programs can for example check for an env var for an
alternative prefix, and the Makefile.am can pass that information to
libtool to put into the wrapper. Then running from uninstalled build
will work.
If running uninstalled build is not a goal, why bother about
LD_LIBRARY_PATH'ing the uninstalled library path at all?
Roumen
Cheers,
Exactly, libtool do home work and set LD_LIBRARY_PATH (DYLD_LIBRARY_PATH
, LIBRARY_PATH, PATH and etc. host/platform specific environment library
search paths) but for application specific environment is author/project
responsibility. I see that you understand case when a library isn't
installed at specified(system) location. This library will load
dependent libraries from default(system) library search path. So the
wrapper script help correct library to be loaded so the libtool home
work is done.
But if user run directly an application installed in non-default
location the user is responsible to set environment.
If its a regression/unit test the correct application environment has to
be set in Makefile{|.in|.am} and the program/library will inherit it.
Roumen
