From: "Stefan Fröberg" <stefan.froberg@petroprogram.com>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: BUG: $ORIGIN does not seem to work
Date: Fri, 26 Jan 2018 23:28:23 +0200 [thread overview]
Message-ID: <9ff4250c-cb19-fd33-c3f3-6600e4932aef@petroprogram.com> (raw)
In-Reply-To: <20180126163403.GF1627@brightrain.aerifal.cx>
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
prev parent reply other threads:[~2018-01-26 21:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-26 13:39 Stefan Fröberg
2018-01-26 14:21 ` Szabolcs Nagy
2018-01-26 23:50 ` Stefan Fröberg
2018-01-27 11:07 ` Szabolcs Nagy
2018-01-27 16:20 ` Stefan Fröberg
2018-01-27 16:42 ` Rich Felker
2018-01-27 17:14 ` Stefan Fröberg
2018-01-27 19:26 ` Szabolcs Nagy
2018-01-27 22:07 ` Stefan Fröberg
2018-01-28 0:54 ` Szabolcs Nagy
2018-02-07 17:35 ` Rich Felker
2018-02-07 20:28 ` Szabolcs Nagy
2018-01-26 16:34 ` Rich Felker
2018-01-26 21:28 ` Stefan Fröberg [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ff4250c-cb19-fd33-c3f3-6600e4932aef@petroprogram.com \
--to=stefan.froberg@petroprogram.com \
--cc=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).