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.

I can't imagine what the present behavior is good for. I'm sure it's
not correct.

> # /usr/local/bin/foo
> cannot locate shared object ../somedir/.libs/libfoo.so
> 
> # mkdir -p ../somedir/.libs
> # cp /usr/local/lib/libfoo.so ../somedir/.libs
> # /usr/local/bin/foo
> foo!
> 
> # cd ..
> # /usr/local/bin/foo
> cannot locate shared object ../somedir/.libs/libfoo.so
> 
> and so on...
> 
> I was actually able to get the latest GNOME built and working even with
> this problem; it required some creative use of symlinks. Blech. ;)
> 
> I'm upgrading to a more recent -current anyway, so maybe this prob will
> just go away with the upgrade. Then again...perhaps this is a known
> issue with the -current toolchain? If so, are there any workarounds or
> fixes known? 
> 
> tia,
> 
> --
> nverenin@san.rr.com
>