Question about DT_RPATH $ORIGIN processing

Question about DT_RPATH $ORIGIN processing

[Tom Kacvinsky]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

I have an executable with a DT_RPATH (not DT_RUNPATH) that consists solely
of
$ORIGIN/lib64 (via the the linker option -Wl,-rpath=$ORIGIN/lib64, with
appropriate shell escaping).

What  see when running strace is the following when trying to load one of
the program's
dependent libraries

83084 open("/opt/prog/lib64/tls/x86_64/libfoo.so", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
83084 stat("/opt/prog/lib64/tls/x86_64", 0x7ffedf338c70) = -1 ENOENT (No
such file or directory)
83084 open("/opt/prog/lib64/tls/libfoo.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
83084 stat("/opt/prog/lib64/tls", 0x7ffedf338c70) = -1 ENOENT (No such file
or directory)
83084 open("/opt/prog/lib64/x86_64/libfoo.so", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
83084 stat("/opt/prog/lib64/x86_64", 0x7ffedf338c70) = -1 ENOENT (No such
file or directory)
83084 open("/opt/prog/lib64/libfoo.so", O_RDONLY|O_CLOEXEC) = 3

I thought it would just go straightaway to the last line.  I don't
understand why there is a search in the other directories when processing
DT_RPATH with $ORIGIN.

Also of note, I did not use `Wl,-z,origin as my research on this
informed me that this option is ignored on x86_64 Linux.

Using glibc 2.17 on a CentOS 7 distribution, binutils 2.39 for linking.

Thanks,

Tom

Re: Question about DT_RPATH $ORIGIN processing

[Tom Kacvinsky]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

On Sun, Nov 20, 2022 at 9:15 AM Tom Kacvinsky <tkacvins@gmail.com> wrote:

> I have an executable with a DT_RPATH (not DT_RUNPATH) that consists solely
> of
> $ORIGIN/lib64 (via the the linker option -Wl,-rpath=$ORIGIN/lib64, with
> appropriate shell escaping).
>
> What  see when running strace is the following when trying to load one of
> the program's
> dependent libraries
>
> 83084 open("/opt/prog/lib64/tls/x86_64/libfoo.so", O_RDONLY|O_CLOEXEC) =
> -1 ENOENT (No such file or directory)
> 83084 stat("/opt/prog/lib64/tls/x86_64", 0x7ffedf338c70) = -1 ENOENT (No
> such file or directory)
> 83084 open("/opt/prog/lib64/tls/libfoo.so", O_RDONLY|O_CLOEXEC) = -1
> ENOENT (No such file or directory)
> 83084 stat("/opt/prog/lib64/tls", 0x7ffedf338c70) = -1 ENOENT (No such
> file or directory)
> 83084 open("/opt/prog/lib64/x86_64/libfoo.so", O_RDONLY|O_CLOEXEC) = -1
> ENOENT (No such file or directory)
> 83084 stat("/opt/prog/lib64/x86_64", 0x7ffedf338c70) = -1 ENOENT (No such
> file or directory)
> 83084 open("/opt/prog/lib64/libfoo.so", O_RDONLY|O_CLOEXEC) = 3
>
> I thought it would just go straightaway to the last line.  I don't
> understand why there is a search in the other directories when processing
> DT_RPATH with $ORIGIN.
>
> Also of note, I did not use `Wl,-z,origin as my research on this
> informed me that this option is ignored on x86_64 Linux.
>
> Using glibc 2.17 on a CentOS 7 distribution, binutils 2.39 for linking.
>

I put on my detective cap and found - I think - that the extra search paths
are coming from elf/dl-hwcaps.c.
This is on the 2.17 release tag, haven't checked against HEAD.

Is this a correct assessment?

Tom

Re: Question about DT_RPATH $ORIGIN processing

[Florian Weimer]

* Tom Kacvinsky via Libc-alpha:

> I put on my detective cap and found - I think - that the extra search paths
> are coming from elf/dl-hwcaps.c.
> This is on the 2.17 release tag, haven't checked against HEAD.
>
> Is this a correct assessment?

Correct.  We no longer use this mechanism in the current, unreleased
version, but on some architectures, you'll notice glibc-hwcaps
subdirectory lookups instead.

Thanks,
Florian