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