Re: [PATCH][v2] Add dynamic linker support for $EXEC_ORIGIN.

[Brooks Moses <bmoses at google dot com>]

Hi, Benjamin,

No worries -- it looks like the reason this wasn't merged was simply
that I dropped the ball on getting back to Carlos with a proper
explanation and revised patch.  I'd blame parent-of-small-child brain
(as mine was about 18 months at that point in time, only a bit older
than Carlos's), but that's not really fair to the small child in
question.  :)

Anyway, thanks for reminding me about this!  I'll see if I can rebase
it and resubmit.

Meanwhile, Carlos, while I'm rebasing the patch, here's a better
sketch of the description of why this is useful -- let me know if this
makes sense or if you have questions, and I'll use that to write an
improved explanation with the new patch:

(Quick summary: $EXEC_ORIGIN in rpaths is like $ORIGIN, but it expands
to the executable's path as passed to execve(), rather than resolving
symlinks in the executable's path as $ORIGIN does.)

The Google build farm sticks the built artifacts in a
content-addressed file system [1].  When some of our systems are
running test programs, they set up a symlink forest to map the
content-addressed storage paths to something sensible.  As a
simplified example with made-up details, you might have something
like:

   ls $my_build_directory -lR
     foo/my_program -> /cas/3b36eaa4/3b36eaa4-a337-4186-a614-653a8033d557
     bar/my_dylib.so -> /cas/171f0b2a/171f0b2a-c176-4c56-ad98-f9b5d8cfcc5c

So, we'd like for foo/my_program to load bar/my_dylib.so, and to do
that it needs an executable-relative path in the rpath, since
$my_build_directory is arbitrary (and we want a hermetic build system
that isn't affected by the build directory).  However, using $ORIGIN
doesn't work, because it traces the symlinks back into the
content-addressed file space, and the paths there depend on the exact
content of the dynamic lib we're linking to -- and there may not even
be a file named "my_dylib.so" back there anyway.

By contrast, "$EXEC_ORIGIN/../bar" works fine, and is independent of
$my_build_directory and of the exact content of my_dylib.so.

- Brooks


[1] http://google-engtools.blogspot.com/2011/10/build-in-cloud-distributing-build.html
has some details, for the curious.


On Mon, Oct 23, 2017 at 10:07 PM, Benjamin Peterson <bp@benjamin.pe> wrote:
>
> Hi,
> Sorry to dredge up this old thread, but is there a reason this wasn't merged
> into upstream? I just ran into a case where this would be useful.
>
> Servus,
> Benjamin