Re: BUG: $ORIGIN does not seem to work

[Rich Felker <dalias@libc.org>]

On Fri, Jan 26, 2018 at 03:39:23PM +0200, Stefan Fröberg wrote:
> Hello
> 
> On glibc the following:
> 
> gcc  -o x -Wl,-rpath='$ORIGIN/lib' x.c -L ./lib -lcrypto
> 
> or
> 
> gcc  -o x -Wl,-rpath,'$ORIGIN/lib' x.c -L ./lib -lcrypto
> 
> Gives me binary with relative library path
> 
> ldd x
>     linux-vdso.so.1 (0x00007ffcb6bee000)
> *    libcrypto.so.1.0.0 => /home/wizard/kal-el/lib/libcrypto.so.1.0.0
> (0x00007f0bc3593000)**
> *    libc.so.6 => /lib64/libc.so.6 (0x00007f0bc31e2000)
>     libdl.so.2 => /lib64/libdl.so.2 (0x00007f0bc2fde000)
>     libz.so.1 => /lib64/libz.so.1 (0x00007f0bc2dc7000)
>     /lib64/ld-linux-x86-64.so.2 (0x00007f0bc39d2000)
> 
> cp -rap kal-el/* batman/
> ldd x
>     linux-vdso.so.1 (0x00007ffdbf0b6000)
> *    libcrypto.so.1.0.0 => /home/wizard/batman/lib/libcrypto.so.1.0.0
> (0x00007fb682149000)**
> *    libc.so.6 => /lib64/libc.so.6 (0x00007fb681d98000)
>     libdl.so.2 => /lib64/libdl.so.2 (0x00007fb681b94000)
>     libz.so.1 => /lib64/libz.so.1 (0x00007fb68197d000)
>     /lib64/ld-linux-x86-64.so.2 (0x00007fb682588000)
> 
> 
> But trying the same with musl does not seem to work?
> ldd x
> /lib/ld-musl-x86_64.so.1 (0x7f07372e2000)
>     libc.so => /lib/ld-musl-x86_64.so.1 (0x7f07372e2000)
> 
> and if i remove the -L ./lib from the command it uses system library
> gcc  -o x -Wl,-rpath,'$ORIGIN/lib'  x.c   -lcrypto
> ldd xx
>     /lib/ld-musl-x86_64.so.1 (0x7fdd8618d000)
>     libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x7fdd85ed7000)
>     libc.so => /lib/ld-musl-x86_64.so.1 (0x7fdd8618d000)
> 
> 
> GCC version 7.2 and musl 1.1.18
> 
> GCC configured with the following:
> gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-musl/7.2.0/lto-wrapper
> Target: x86_64-linux-musl
> Configured with: ../configure --prefix=/usr --build=x86_64-linux-musl
> --enable-languages=c,c++,lto --disable-multilib --disable-nls
> --disable-libmudflap --disable-libsanitizer --with-system-zlib
> --disable-werror --enable-gold=yes --enable-ld=yes --enable-plugin
> --enable-plugins --enable-lto --enable-default-pie --enable-default-ssp
> --with-linker-hash-style=gnu --enable-libgomp --with-fpmath=sse
> Thread model: posix
> gcc version 7.2.0 (GCC)
> 
> 
> Best regards
> Stefan Fröberg
> 
> x.c
> ------------------------------
> #include <stdio.h>
> #include <openssl/ssl.h>
> 
> int main(void)
> {
>    
> OPENSSL_init_crypto(OPENSSL_INIT_NO_ADD_ALL_CIPHERS|OPENSSL_INIT_NO_ADD_ALL_DIGESTS,NULL);
>     return(0);
> }
> 

Do you possibly have LD_LIBRARY_PATH set in the environment? glibc
supports both DT_RPATH and DT_RUNPATH with different semantics.
DT_RPATH comes before LD_LIBRARY_PATH and is considered deprecated by
them, whereas DT_RUNPATH comes after LD_LIBRARY_PATH but only affects
search for direct dependencies not indirect ones.

musl only supports one behavior (both are treated as the same). The
rpath/runpath search always comes after LD_LIBRARY_PATH (so you can
override it) and it always affects direct AND indirect dependency
loading.

If that's not the issue, we probably need to see more details (like
readelf output) to know what's going on.

Rich