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-26 01:32:03

On Sat, Oct 25, 2008 at 06:29:34PM -0500, Steve M. Robbins wrote:
> On Sat, Oct 25, 2008 at 08:34:33AM -0400, Alexander Sack wrote:
> > > 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.
> > 
> > Well then why are we setting it up in the first place?
> 
> That's the $64,000 question.  I'm hoping someone who understands
> jam will answer it.

Using the magic of "svn blame", we see that Vladimir Prus did the deed:

------------------------------------------------------------------------
r33307 | vladimir_prus | 2006-03-10 05:51:24 -0600 (Fri, 10 Mar 2006) | 7 lines

Set RUN_PATH variable when linking with gcc, which allows the testing
rules (run/unit-test) to set LD_LIBRARY_PATH variables when running test.

This is to accomotate cases where gcc is installed in non-standard location,
and the path to that location is not in LD_LIBRARY_PATH, but the binaries
still want to link to libstdc++.

------------------------------------------------------------------------
--- gcc.jam     (revision 33306)
+++ gcc.jam     (revision 33307)
@@ -57,6 +57,18 @@
         linker = gnu ;
     }
     init-link-flags gcc $(linker) $(condition) ;
+
+    # If gcc is installed in non-standard location, we'd need to
+    # add LD_LIBRARY_PATH when running programs created with it
+    # (for unit-test/run rules).
+    if $(command)
+    {
+        local path = [ common.get-absolute-tool-path $(command[-1]) ] ;
+        local lib_path = $(path:D)/lib ;
+        flags gcc.link RUN_PATH : $(lib_path) ;
+    }
+
+
 }
------------------------------------------------------------------------

Anyone who installs gcc in a non-standard location with shared
libstdc++ will have to inform the run-time linker of the location of
libstdc++ in some manner.  For example, by setting LD_LIBRARY_PATH.
Otherwise, *no* C++ program will run on this system.

So this bit of jam magic exists to "fix" the environment of a user for
whom no C++ program will run.  This piece of gcc.jam has evolved, each
time adding more libraries to lib_path.  Manifestly, it is still
broken.  

To what degree should Boost.Build "fix" the user's environment?

My take is that the cure is worse than the disease, and should
be removed.

Vladimir: is this solving a real problem, or a theoretical one?

Cheers,
-Steve