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.
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.
Andrew.
