Re: [Boost-build] gcc.jam weirdness (was: Boost-1.36.0 FreeBSD patches for review)

Subject: Re: [Boost-build] gcc.jam weirdness (was: Boost-1.36.0 FreeBSD patches for review)
From: Steve M. Robbins (steve_at_[hidden])
Date: 2008-10-24 23:13:02

On Fri, Oct 24, 2008 at 09:30:42AM -0400, Alexander Sack wrote:
> On Fri, Oct 24, 2008 at 4:04 AM, Steve M. Robbins <steve_at_[hidden]> wrote:
> > On Thu, Oct 23, 2008 at 10:46:58PM -0400, Alexander Sack wrote:
> >
> >> In the meantime, I would like comments on the following three patches:
> >
> >> - gcc.jam.patch
> >>
> >> The gcc toolset is set with a LD_LIBRARY_PATH without /lib.
> >
> > My reading of the linux runtime loader manpage suggests that
> > LD_LIBRARY_PATH should be reserved for *NONSTANDARD* library
> > locations.  Here is an excerpt from "man ld-linux":
> >
> >    The necessary shared libraries needed by the program are searched
> >    for in the following order
> >
> >    o   Using the environment variable LD_LIBRARY_PATH
> >        (LD_AOUT_LIBRARY_PATH for a.out programs).  Except if the
> >        executable is a setuid/setgid binary, in which case it is
> >        ignored.
> >
> >   o    From the cache file /etc/ld.so.cache which contains a compiled
> >        list of candidate libraries previously found in the augmented
> >        library path.
> >
> >   o    In the default path /lib, and then /usr/lib.
> >
> >
> > In my view, it would be a mistake to add /lib.  Alexander: what
> > problem does that solve for you?

> 2) The default even on Linux and gcc's rtld is /lib as you can see
> above.  Putting it in /lib is not wrong in my book but it may not
> achieve what this line is really looking for (well get to that in a
> sec)

Yes: the run-time loader searches /lib, /usr/lib, and the like.  Since
LD_LIBRARY_PATH is for *NONSTANDARD* locations, you *do* *not* put
/lib into it.

In general, LD_LIBRARY_PATH is empty; it is mainly useful to kludge
around a poorly-set up system.  For example, if someone installs
shared libs in /some/weird/place that isn't placed into ld.so.cache by
the admin.

> When you set the LD_LIBRARY_PATH to search
> /usr/lib:/usr/lib32:/usr/lib64 what occurs is rtld picks up the
> version for /usr/lib32 SINCE there exists the major number version of
> say libutil.so.5 and barfs.

Sure; my propsal is NOT to set the LD_LIBRARY_PATH variable at all.  The
system will do the right thing.

Regards,
-Steve