[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libjava testsuite problem under i686-pc-linux-gnu

From: Alexandre Oliva
Subject: Re: libjava testsuite problem under i686-pc-linux-gnu
Date: 28 May 2001 23:13:39 -0300
User-agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Academic Rigor)

On May 28, 2001, "John David Anglin" <address@hidden> wrote:

> I still don't understand why libtool doesn't use `-B' and `-L' when it
> creates the `rpath' list for building the preinstall version of an
> application.

Because -B and -L specify static link (compile)-time search paths,
whereas -R and -rpath specify the dynamic link (run)-time search path.
If libtool got -rpath from -B and you built any executable for the
target in the GCC tree, that executable would search for libgcc in the
build tree, even after being installed.

> Why does it matter whether a library is a libtool library
> in the magic .libs subdirectory or a non-libtool library?

libtool knows whether a library is in the build tree or has already
been installed, and creates executables that, when installed, look for
libraries in their installed locations, but that locate libraries in
the build tree when run inside the build tree.

It get increasingly difficult to do this when one to-be-installed
library depends on another yet-to-be-installed library.  If we want to
get that library to automatically find its dependencies, we may need
to create two copies of that library, since you have found out
LD_LIBRARY_PATH doesn't affect this search.  Libtool takes care of
this problem too, but it can only do it when the library being linked
in is a libtool library.

Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  address@hidden,}
CS PhD student at IC-Unicamp        address@hidden,}
Free Software Evangelist    *Please* write to mailing lists, not to me

reply via email to

[Prev in Thread] Current Thread [Next in Thread]