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: Vladimir Prus (ghost_at_[hidden])
Date: 2008-10-26 03:38:14

On Sunday 26 October 2008 08:32:03 Steve M. Robbins wrote:
> 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?

I believe the issue was that Martin was running tests with zillion
versions of gcc at the same time. Then, when running any given test
binary, you better point it at the lib dirs of the right compiler.
Global LD_LIBRARY_PATH is not going to work -- as you have 5 different
compilers, some of them using same sonames for libraries. 

- Volodya