On 02/14/2010 11:35 AM, David Kirkby wrote: > On 11 February 2010 18:49, Andrew Haley <aph@xxxxxxxxxx> wrote: > >> LD_OPTIONS=-R/usr/local/gcc-4.3.4/lib -L/usr/local/gcc-4.3.4/lib >> >> is wrong, BTW. You want the -R arg to point to your mpfr's lib as well. >> >> (This is the -rpath I talked about. We tend to avoid it like the plague, >> as it means you can't move libraries.) > > I'd specifically put mpir and mpfr libraries in the same place I > intended put gcc, so that was not the issue. The problem was I'd put > gcc-4.3.4 in the LD_OPTIONS, when it should have been gcc-4.4.3 - I'd > transposed the last two digits. > > To my logic, LD_LIBRARY_PATH should be used when one moves binaries. > That is one of its uses. For other reasons tasks is is a disaster. For > example, it can't be used if creating binaries with the setuid or > setgid bit set. (Well, it can be used, but it will be ignored!) Quite right too. I hope there are not going to be very many of those in non-system packages! > See the link below "Why LD_LIBRARY_PATH is bad" by David Barr. > > http://xahlee.org/UnixResource_dir/_/ldpath.html Well, he's advocating -rpath. It's an opinion he gets to have, but IMO -rpath is even more of a disaster than LD_LIBRARY_PATH. The use of -rpath is, I suspect, related to the practice of putting packages under /opt in Solaris (and I think other SYSV based systems.) We don't much do that in GNU/Linux because of the way that our package managers work: our libraries go into /lib, /usr/lib, or somesuch, binaries into /bin, and so on. The system paths almost always do just fine, so there's no need for -rpath or for LD_LIBRARY_PATH. However, if you are going to put each package, with its binaries and libraries, into its own directory under /opt, then you are probably going to need -rpath or something similar. It's not great, of course, and you may end up with several versions of libfoo.so, each in a separate package under /opt. There is no really perfect solution to this problem. On my GNU/Linux system a couple of packages end up modifying /etc/ld.so.conf, and this is because the upstream maintainers of those packages have their own install tree that doesn't play well with the rest of the system, but there really are only a couple of packages like that. Andrew.
