This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][v2] Add dynamic linker support for $EXEC_ORIGIN.
- From: Brooks Moses <bmoses at google dot com>
- To: libc-alpha <libc-alpha at sourceware dot org>
- Cc: "Carlos O'Donnell" <carlos at redhat dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Stan Shebs <stanshebs at google dot com>, Benjamin Peterson <bp at benjamin dot pe>
- Date: Tue, 24 Oct 2017 01:07:20 -0700
- Subject: Re: [PATCH][v2] Add dynamic linker support for $EXEC_ORIGIN.
- Authentication-results: sourceware.org; auth=none
- References: <1386886419-18491-1-git-send-email-bmoses@google.com> <20171024050715.5F4137F94E@mailuser.nyi.internal>
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