tech-toolchain archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Fixing $ORGIN RPATHs - at least some of them
On Tue, Nov 07, 2017 at 10:01:32PM +0000, David Holland wrote:
> On Tue, Nov 07, 2017 at 06:58:13PM +0100, Kamil Rytarowski wrote:
> > I mean that a program can exist as two or more files, like:
> >
> > /sbin/dump
> > /sbin/rdump
> >
> > Some software (for example in LLVM) require to return the exact executed
> > program, not a random executable based on an inode value. Right now LLVM
> > is guessing program exec name on NetBSD reading argv[0], as the
> > sysctl(2) version wasn't reliable.
>
> This is why the whole notion of trying to get the name of the
> executable is flawed.
What we really want (for the topic of this thread) is: a reference to
the directory the original binary was loaded from and a dlopenat() call
for use by ld.elf_so if $ORIGIN is present in RPATH.
ld.elf_so does not care about the exe name (and most uses of rust's
std::env::current_exe() that I could find immediately strip it back to
the last / character, that is: care about the directory name only - or
are mostly cosmetic and would better use argv[0]).
Also note that for cases like this all hard cases (like binaries doing
chroot, directories being unreadable, directories being moved, ...)
are irrelevant - failure to use $ORIGIN after one of those would count
as operator error.
Martin
Home |
Main Index |
Thread Index |
Old Index