Re: What hack in ld.so?

[Robert Woodcock <rcw@debian.org>]

Alexandre Oliva wrote:
>The point is that you've just been asking for libtool not to use
>-rpath at all,

Yes, I think this is the correct solution.

>but this would only work for people who create .deb or .rpm binary
>packages,

You fill this house with lies. It works for anyone putting libraries in
standard places, "standard" being defined by the admin, who has write
access to /etc/ld.so.cache.

Users can work around this by, at worst, creating a wrapper script to set
LD_LIBRARY_PATH.

For example:

frantica:~/apt/build/bin$ ./apt-get
./apt-get: error in loading shared libraries
libapt-pkg.so.2.0: cannot open shared object file: No such file or directory
frantica:~/apt/build/bin$ cat apt-get-wrapper
#!/bin/sh
LD_LIBRARY_PATH=/home/rcw/apt/build/bin exec /home/rcw/apt/build/bin/apt-get "$@"
frantica:~/apt/build/bin$ ls -l apt-get-wrapper
-rwxr-xr-x   1 rcw      rcw            87 Jan 31 02:11 apt-get-wrapper*
frantica:~/apt/build/bin$ ./apt-get-wrapper
apt 0.3.0 for i386 [...]

This is what our ld.so has done for years, this is what our users expect,
and this is what has determined Linux's library placement for every other
transition it has had to make. It's safe to say that will not change.

Hardcoded pathnames to libraries are evil, you can't blame people for trying
to get rid of them, especially when they start breaking left and right the
minute things move around.
-- 
Robert Woodcock - rcw@debian.org
"It's like a love-hate relationship, but without the love." -- jwz, on linux