[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9ff4250c-cb19-fd33-c3f3-6600e4932aef@petroprogram.com>
Date: Fri, 26 Jan 2018 23:28:23 +0200
From: Stefan Fröberg <stefan.froberg@...roprogram.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: BUG: $ORIGIN does not seem to work
Hello Rich
Rich Felker kirjoitti 26.01.2018 klo 18:34:
> 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.
All those environment variables are empty, in both 64-bit Gentoo host
and also
inside the 64-bit chrooted musl test environment.
>
> If that's not the issue, we probably need to see more details (like
> readelf output) to know what's going on.
>
> Rich
Okay, just please tell me what I have to do.
Best Regards
Stefan Fröberg
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.
