Matt Thomas wrote:
> 
> At 10:05 AM 4/3/00 , Frederick Bruckman wrote:
> >On Sun, 2 Apr 2000, NJ Verenini wrote:
> >
> > > It manifests primarily with GNU software that builds .so with
> > > libtool...executables linked against shared objects in temporary build
> > > dirs (example: ../somedir/.libs/libfoo.so) seem to not understand when
> > > that .so is available via LD_LIBRARY_PATH. Hence, after installing app
> > > into /usr/local/bin and libfoo.so into /usr/local/lib, we get something
> > > like this:
> >
> >It's not only ELF--a.out can encode run-time paths, too. The problem
> >seems to be that ld{,_elf}.so interprets relative paths for shared
> >libraries as relative to the _current_ _directory_, rather than
> >relative to the _executable_. Please verify.
> 
> Of course it's relative to the current directory.  The
> loader doesn't even know the location of the executable.
> --
> Matt Thomas               Internet:   matt@3am-software.com
> 3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
> Cupertino, CA             Disclaimer: I avow all knowledge of this message

The chain of events goes something like this:

1) build process makes some shared objects, puts them in a temporary
directory (say .libs)
2) executables are linked against those shared objects in the temporary
directory
3) installation installs bin and libs in their usual places
4) when trying to run bin, loader tries to get library from .libs,
-instead- of looking in LD_LIBRARY_PATH

The problem, of course, is that you are likely to no longer be in the
build directory, so the loader reports it can't find the shared object.

I looked at some of the software with the problem (how it built
executables), and they all seem to do something like this:

gcc .libs/libfoo.so -o foo foo.c

instead of something like

gcc -o foo foo.c -L./libs -lfoo

Maybe that is part of the problem...

--
nverenin@san.rr.com