[patch] releases.html

[Alexandre Oliva]

On Feb 13, 2001, "Zack Weinberg" <zackw@Stanford.EDU> wrote:

> On Tue, Feb 13, 2001 at 06:38:29AM -0200, Alexandre Oliva wrote:

>> Besides, you have to make sure the executables created in the build
>> tree use libraries from the build tree, and those that you install
>> look for libraries where they're installed.  In particular, you don't
>> want executables in the build tree to use previously-installed
>> libraries nor the installed ones to search the build tree.  And, on
>> most OSs, setting LD_LIBRARY_PATH or equivalent is not enough to
>> ensure you get the right libraries.

> Details?

Assume you configure GCC with some non-/usr/local prefix.  You'd like
the installed gcc programs to automatically find the installed
libraries, wouldn't you?  So that you wouldn't have to set
LD_LIBRARY_PATH or equivalent (where available; on some systems, such
as HPsUX, it's only available if you link the program using some
particular linker flag).

So, you link the programs with the equivalent of -rpath ${libdir}.
This may be doable with some combination of flags and/or
environment-variable setting on various platforms.  On some platforms,
it's ok to use multiple flags, and they're combined properly; on
others, you have to specify all search directories in a single option,
otherwise only the last one prevails.

On some platforms, it can only be done after the library itself has
already been installed.  On some platforms, the -rpath switch is -L,
and, since you don't want installed binaries to depend on libraries in
the build tree, you'll want to relink the program at installation
time, just like in the previous case.  On some other platforms, the
directories specified with -rpath or equivalent are searched *before*
that of LD_LIBRARY_PATH.

So, on a number of platforms (GNU/Linux included), if you link the
program such that it searches the installation directory for
libraries, it'll do so even if you start it from the build directory.
Even if you set LD_LIBRARY_PATH.  Cool, eh?

> I'm not sure it can be got completely right in the general case

It can't.  But, with libtool, you get as close as possible to that.
That's one of the reasons why it's as complex as it is.  A lot of
knowledge about the oddities of the way each particular operating
system decided to implement shared libraries was put into it.  The
choices are using a complex yet relatively reliable solution or start
by duplicating it in a more limited way and let it grow to fix all the
problems people find over time until it becomes almost as complex as
libtool, but not as simple to use in other projects.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me