Re: Fixing the glibc runtime linker

[Paul Pluzhnikov <ppluzhnikov () google com>]

On Fri, Feb 20, 2015 at 1:22 AM,  <Casper.Dik () oracle com> wrote:
> > FWIW, relative RPATHs are quite fundamental to our test execution
> > environment, and any patch that unconditionally ignores them would
> > have to be reverted in our tree.

It turns out I was mistaken: we don't use relative RPATHs after all.

> But wouldn't that make the libraries and executables less reliable?

Our testing infrastructure is described in some detail here:
http://google-engtools.blogspot.com/2011/06/testing-at-speed-and-scale-of-google.html

The essential problem is that the paths to all the libraries in the cloud
are effectively unpredictable. They are however predictable relative to
$ORIGIN, which is what we actually use [1].

> They can pick up random libraries or cause some delays when one of the
> relative paths points to a NFS mounted directory.

We only build tests that way, not final binaries. Random libraries and
NFS are not a concern for us, because the 'in the cloud' environment is
tightly controlled -- we know exactly what files the test will see at
runtime (relative to $ORIGIN).

> Any reason you can't change to using LD_LIBRARY_PATH for testing?

We used to use LD_LIBRARY_PATH, but it has several problems. Consider a
Python or Java program that needs to load some C++ shared library, and
also wants to fork off a separate C++ executable. Consider further that
the python may be built for ix86, while the C++ executable may be built
for x86_64.

What should the LD_LIBRARY_PATH look like? Should it leak from python into
C++ executable? It's complicated :-)



[1] This isn't strictly true either, for complicated reasons irrelevant
to current discussion.

-- 
Paul Pluzhnikov