On 02/14/2010 03:43 PM, Dr. David Kirkby wrote: > Andrew Haley wrote: >> 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. > > I'm not convinced it should be necessary to have multiple copies of > libfoo. I chose to put gmp and mpfr in the same directory as the gcc > libs, in the hope it might just be easier for gcc to find them. But I > doubt it was essential to do this if LD_OPTIONS is set correctly. If gcc > can find the libs by use of LD_OPTIONS, then that should be enough. Sure, but if you've installed them locally for gcc, and no-one else knows they're there, then there's no point them being shared libraries. All you get is slower access and more meory usage. > I normally tend to use /usr/local personally, as /opt is a system > directory, and I'd prefer to keep my own files separately. /opt, along > with the rest of Solaris sits on a couple of 500 GB mirrored disks. > /usr/local, and all user files sit on a couple of 2 TB mirrored disks. > So even if Solaris gets totally screwed up, and a reinstall is quickest, > I know my own files are on separate disks. > >> 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. > > That I assume needs root access to install, which IMHO is a bad thing. Well, that's a matter of system policy, but if you have a shared library then you might as well share it, and for the fairly obvious security reasons you need root access to put it in a shared place. I'm not aware that any other approach is possible, even in theory. Andrew.
