[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180126163403.GF1627@brightrain.aerifal.cx>
Date: Fri, 26 Jan 2018 11:34:03 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: BUG: $ORIGIN does not seem to work
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
