Re: What hack in ld.so?
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
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
./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
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*
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 - email@example.com
"It's like a love-hate relationship, but without the love." -- jwz, on linux