* BUG: $ORIGIN does not seem to work @ 2018-01-26 13:39 Stefan Fröberg 2018-01-26 14:21 ` Szabolcs Nagy 2018-01-26 16:34 ` Rich Felker 0 siblings, 2 replies; 14+ messages in thread From: Stefan Fröberg @ 2018-01-26 13:39 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 2360 bytes --] 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); } [-- Attachment #2: Type: text/html, Size: 3174 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 2018-01-26 13:39 BUG: $ORIGIN does not seem to work Stefan Fröberg @ 2018-01-26 14:21 ` Szabolcs Nagy 2018-01-26 23:50 ` Stefan Fröberg 2018-01-26 16:34 ` Rich Felker 1 sibling, 1 reply; 14+ messages in thread From: Szabolcs Nagy @ 2018-01-26 14:21 UTC (permalink / raw) To: musl * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-26 15:39:23 +0200]: > 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) > > $ORIGIN in rpath works fine in musl you are doing something wrong but it's hard to tell what: your ldd command is looking at the wrong binary, we don't know what ldd you are using (e.g. use ld-*-musl.so.1 --list foo to make this explicit), it's not clear if the binary has $ORIGIN set up correctly since you showed a gcc command line instead of readelf -d of the generated executable, we don't know what paths have the library and what paths the ldso tried (you can check this by strace). (there are some differences between musl and glibc: e.g. glibc expands $ORIGIN in dlopen too while musl does not, however in your case musl should work) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 2018-01-26 14:21 ` Szabolcs Nagy @ 2018-01-26 23:50 ` Stefan Fröberg 2018-01-27 11:07 ` Szabolcs Nagy 0 siblings, 1 reply; 14+ messages in thread From: Stefan Fröberg @ 2018-01-26 23:50 UTC (permalink / raw) To: Szabolcs Nagy; +Cc: musl Hello Szabolcs My ldd is just symbolic link inside musl chroot environment, to /lib/ld-musl-x86_64.so.1 and it's symbolic link to /lib/libc.so Here is readelf output of that test program readelf -d x Dynamic section at offset 0xe10 contains 24 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so] 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/lib] 0x000000000000000c (INIT) 0x598 0x000000000000000d (FINI) 0x812 0x000000006ffffef5 (GNU_HASH) 0x220 0x0000000000000005 (STRTAB) 0x390 0x0000000000000006 (SYMTAB) 0x258 0x000000000000000a (STRSZ) 241 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0x201000 0x0000000000000002 (PLTRELSZ) 48 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x568 0x0000000000000007 (RELA) 0x4c0 0x0000000000000008 (RELASZ) 168 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffb (FLAGS_1) Flags: PIE 0x000000006ffffffe (VERNEED) 0x4a0 0x000000006fffffff (VERNEEDNUM) 1 0x000000006ffffff0 (VERSYM) 0x482 0x000000006ffffff9 (RELACOUNT) 2 0x0000000000000000 (NULL) 0x0 So the $ORIGIN/lib is there but for some reason ldd won't show it??? Best Regards Stefan Fröberg Szabolcs Nagy kirjoitti 26.01.2018 klo 16:21: > * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-26 15:39:23 +0200]: >> 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) >> >> > $ORIGIN in rpath works fine in musl > > you are doing something wrong > > but it's hard to tell what: your ldd command is looking at > the wrong binary, we don't know what ldd you are using (e.g. > use ld-*-musl.so.1 --list foo to make this explicit), it's > not clear if the binary has $ORIGIN set up correctly since > you showed a gcc command line instead of readelf -d of the > generated executable, we don't know what paths have the > library and what paths the ldso tried (you can check this > by strace). > > (there are some differences between musl and glibc: > e.g. glibc expands $ORIGIN in dlopen too while musl does > not, however in your case musl should work) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 2018-01-26 23:50 ` Stefan Fröberg @ 2018-01-27 11:07 ` Szabolcs Nagy 2018-01-27 16:20 ` Stefan Fröberg 0 siblings, 1 reply; 14+ messages in thread From: Szabolcs Nagy @ 2018-01-27 11:07 UTC (permalink / raw) To: Stefan Fröberg; +Cc: musl * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-27 01:50:21 +0200]: > My ldd is just symbolic link inside musl chroot environment, to > /lib/ld-musl-x86_64.so.1 > and it's symbolic link to /lib/libc.so > > Here is readelf output of that test program > readelf -d x > > Dynamic section at offset 0xe10 contains 24 entries: > Tag Type Name/Value > 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1] ^^^^^^^^^^^^^^^^ this looks like the wrong library version if you had straced the ldd output you would have seen that musl tries to open lib/libcrypto.so.1.1, but you probably only have lib/libcrypto.so.1.0.0 based on the glibc ldd output below. at link time you need to make sure ld picks up the right libcrypto. > 0x0000000000000001 (NEEDED) Shared library: [libc.so] > 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/lib] > 0x000000000000000c (INIT) 0x598 > 0x000000000000000d (FINI) 0x812 > 0x000000006ffffef5 (GNU_HASH) 0x220 > 0x0000000000000005 (STRTAB) 0x390 > 0x0000000000000006 (SYMTAB) 0x258 > 0x000000000000000a (STRSZ) 241 (bytes) > 0x000000000000000b (SYMENT) 24 (bytes) > 0x0000000000000015 (DEBUG) 0x0 > 0x0000000000000003 (PLTGOT) 0x201000 > 0x0000000000000002 (PLTRELSZ) 48 (bytes) > 0x0000000000000014 (PLTREL) RELA > 0x0000000000000017 (JMPREL) 0x568 > 0x0000000000000007 (RELA) 0x4c0 > 0x0000000000000008 (RELASZ) 168 (bytes) > 0x0000000000000009 (RELAENT) 24 (bytes) > 0x000000006ffffffb (FLAGS_1) Flags: PIE > 0x000000006ffffffe (VERNEED) 0x4a0 > 0x000000006fffffff (VERNEEDNUM) 1 > 0x000000006ffffff0 (VERSYM) 0x482 > 0x000000006ffffff9 (RELACOUNT) 2 > 0x0000000000000000 (NULL) 0x0 > > So the $ORIGIN/lib is there but for some reason ldd won't show it??? > > Best Regards > Stefan Fröberg > > Szabolcs Nagy kirjoitti 26.01.2018 klo 16:21: > > * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-26 15:39:23 +0200]: > >> 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) > >> > >> > > $ORIGIN in rpath works fine in musl > > > > you are doing something wrong > > > > but it's hard to tell what: your ldd command is looking at > > the wrong binary, we don't know what ldd you are using (e.g. > > use ld-*-musl.so.1 --list foo to make this explicit), it's > > not clear if the binary has $ORIGIN set up correctly since > > you showed a gcc command line instead of readelf -d of the > > generated executable, we don't know what paths have the > > library and what paths the ldso tried (you can check this > > by strace). > > > > (there are some differences between musl and glibc: > > e.g. glibc expands $ORIGIN in dlopen too while musl does > > not, however in your case musl should work) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 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 19:26 ` Szabolcs Nagy 0 siblings, 2 replies; 14+ messages in thread From: Stefan Fröberg @ 2018-01-27 16:20 UTC (permalink / raw) To: Szabolcs Nagy; +Cc: musl Hi Szabolcs Nagy kirjoitti 27.01.2018 klo 13:07: > * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-27 01:50:21 +0200]: >> My ldd is just symbolic link inside musl chroot environment, to >> /lib/ld-musl-x86_64.so.1 >> and it's symbolic link to /lib/libc.so >> >> Here is readelf output of that test program >> readelf -d x >> >> Dynamic section at offset 0xe10 contains 24 entries: >> Tag Type Name/Value >> 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1] > ^^^^^^^^^^^^^^^^ > this looks like the wrong library version > > if you had straced the ldd output you would have seen > that musl tries to open lib/libcrypto.so.1.1, but you > probably only have lib/libcrypto.so.1.0.0 based on the > glibc ldd output below. No, that ldd was run inside, pure, chrooted musl environment. No glibc inside. These are the only libcrypto* files inside that chroot environment: ls -lah /usr/lib/libcrypto.* -rw-r--r-- 1 0 0 5.0M Dec 17 00:24 /usr/lib/libcrypto.a lrwxrwxrwx 1 0 0 16 Dec 17 00:24 /usr/lib/libcrypto.so -> libcrypto.so.1.1 -rwxr-xr-x 1 0 0 3.0M Jan 26 12:58 /usr/lib/libcrypto.so.1.1 Best Regards Stefan > at link time you need to make sure ld picks up the > right libcrypto. > >> 0x0000000000000001 (NEEDED) Shared library: [libc.so] >> 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/lib] >> 0x000000000000000c (INIT) 0x598 >> 0x000000000000000d (FINI) 0x812 >> 0x000000006ffffef5 (GNU_HASH) 0x220 >> 0x0000000000000005 (STRTAB) 0x390 >> 0x0000000000000006 (SYMTAB) 0x258 >> 0x000000000000000a (STRSZ) 241 (bytes) >> 0x000000000000000b (SYMENT) 24 (bytes) >> 0x0000000000000015 (DEBUG) 0x0 >> 0x0000000000000003 (PLTGOT) 0x201000 >> 0x0000000000000002 (PLTRELSZ) 48 (bytes) >> 0x0000000000000014 (PLTREL) RELA >> 0x0000000000000017 (JMPREL) 0x568 >> 0x0000000000000007 (RELA) 0x4c0 >> 0x0000000000000008 (RELASZ) 168 (bytes) >> 0x0000000000000009 (RELAENT) 24 (bytes) >> 0x000000006ffffffb (FLAGS_1) Flags: PIE >> 0x000000006ffffffe (VERNEED) 0x4a0 >> 0x000000006fffffff (VERNEEDNUM) 1 >> 0x000000006ffffff0 (VERSYM) 0x482 >> 0x000000006ffffff9 (RELACOUNT) 2 >> 0x0000000000000000 (NULL) 0x0 >> >> So the $ORIGIN/lib is there but for some reason ldd won't show it??? >> >> Best Regards >> Stefan Fröberg >> >> Szabolcs Nagy kirjoitti 26.01.2018 klo 16:21: >>> * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-26 15:39:23 +0200]: >>>> 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) >>>> >>>> >>> $ORIGIN in rpath works fine in musl >>> >>> you are doing something wrong >>> >>> but it's hard to tell what: your ldd command is looking at >>> the wrong binary, we don't know what ldd you are using (e.g. >>> use ld-*-musl.so.1 --list foo to make this explicit), it's >>> not clear if the binary has $ORIGIN set up correctly since >>> you showed a gcc command line instead of readelf -d of the >>> generated executable, we don't know what paths have the >>> library and what paths the ldso tried (you can check this >>> by strace). >>> >>> (there are some differences between musl and glibc: >>> e.g. glibc expands $ORIGIN in dlopen too while musl does >>> not, however in your case musl should work) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 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 1 sibling, 1 reply; 14+ messages in thread From: Rich Felker @ 2018-01-27 16:42 UTC (permalink / raw) To: musl On Sat, Jan 27, 2018 at 06:20:27PM +0200, Stefan Fröberg wrote: > Hi > > > Szabolcs Nagy kirjoitti 27.01.2018 klo 13:07: > > * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-27 01:50:21 +0200]: > >> My ldd is just symbolic link inside musl chroot environment, to > >> /lib/ld-musl-x86_64.so.1 > >> and it's symbolic link to /lib/libc.so > >> > >> Here is readelf output of that test program > >> readelf -d x > >> > >> Dynamic section at offset 0xe10 contains 24 entries: > >> Tag Type Name/Value > >> 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1] > > ^^^^^^^^^^^^^^^^ > > this looks like the wrong library version > > > > if you had straced the ldd output you would have seen > > that musl tries to open lib/libcrypto.so.1.1, but you > > probably only have lib/libcrypto.so.1.0.0 based on the > > glibc ldd output below. > No, that ldd was run inside, pure, chrooted musl environment. No glibc > inside. > These are the only libcrypto* files inside that chroot environment: > > ls -lah /usr/lib/libcrypto.* > -rw-r--r-- 1 0 0 5.0M Dec 17 00:24 /usr/lib/libcrypto.a > lrwxrwxrwx 1 0 0 16 Dec 17 00:24 > /usr/lib/libcrypto.so -> libcrypto.so.1.1 > -rwxr-xr-x 1 0 0 3.0M Jan 26 12:58 > /usr/lib/libcrypto.so.1.1 OK, but it still means ld picked up a different version of libcrypto (at link time) and encoded the dependency on that different version. You need to ensure that gcc/ld is searching your lib dir at link time. BTW running the program itself or ldd under strace can be very informative to see what's happening. Rich ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 2018-01-27 16:42 ` Rich Felker @ 2018-01-27 17:14 ` Stefan Fröberg 0 siblings, 0 replies; 14+ messages in thread From: Stefan Fröberg @ 2018-01-27 17:14 UTC (permalink / raw) To: Rich Felker; +Cc: musl Hi Rich Rich Felker kirjoitti 27.01.2018 klo 18:42: > On Sat, Jan 27, 2018 at 06:20:27PM +0200, Stefan Fröberg wrote: >> Hi >> >> >> Szabolcs Nagy kirjoitti 27.01.2018 klo 13:07: >>> * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-27 01:50:21 +0200]: >>>> My ldd is just symbolic link inside musl chroot environment, to >>>> /lib/ld-musl-x86_64.so.1 >>>> and it's symbolic link to /lib/libc.so >>>> >>>> Here is readelf output of that test program >>>> readelf -d x >>>> >>>> Dynamic section at offset 0xe10 contains 24 entries: >>>> Tag Type Name/Value >>>> 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1] >>> ^^^^^^^^^^^^^^^^ >>> this looks like the wrong library version >>> >>> if you had straced the ldd output you would have seen >>> that musl tries to open lib/libcrypto.so.1.1, but you >>> probably only have lib/libcrypto.so.1.0.0 based on the >>> glibc ldd output below. >> No, that ldd was run inside, pure, chrooted musl environment. No glibc >> inside. >> These are the only libcrypto* files inside that chroot environment: >> >> ls -lah /usr/lib/libcrypto.* >> -rw-r--r-- 1 0 0 5.0M Dec 17 00:24 /usr/lib/libcrypto.a >> lrwxrwxrwx 1 0 0 16 Dec 17 00:24 >> /usr/lib/libcrypto.so -> libcrypto.so.1.1 >> -rwxr-xr-x 1 0 0 3.0M Jan 26 12:58 >> /usr/lib/libcrypto.so.1.1 > OK, but it still means ld picked up a different version of libcrypto > (at link time) and encoded the dependency on that different version. > You need to ensure that gcc/ld is searching your lib dir at link time. > > BTW running the program itself or ldd under strace can be very > informative to see what's happening. > > Rich > Well, I can of course try to compile libcrypto again completely from scratch inside that chroot environment and see if it helps. Best Regards Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 2018-01-27 16:20 ` Stefan Fröberg 2018-01-27 16:42 ` Rich Felker @ 2018-01-27 19:26 ` Szabolcs Nagy 2018-01-27 22:07 ` Stefan Fröberg 1 sibling, 1 reply; 14+ messages in thread From: Szabolcs Nagy @ 2018-01-27 19:26 UTC (permalink / raw) To: Stefan Fröberg; +Cc: musl * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-27 18:20:27 +0200]: > Szabolcs Nagy kirjoitti 27.01.2018 klo 13:07: > > * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-27 01:50:21 +0200]: > >> My ldd is just symbolic link inside musl chroot environment, to > >> /lib/ld-musl-x86_64.so.1 > >> and it's symbolic link to /lib/libc.so > >> > >> Here is readelf output of that test program > >> readelf -d x > >> > >> Dynamic section at offset 0xe10 contains 24 entries: > >> Tag Type Name/Value > >> 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1] > > ^^^^^^^^^^^^^^^^ > > this looks like the wrong library version > > > > if you had straced the ldd output you would have seen > > that musl tries to open lib/libcrypto.so.1.1, but you > > probably only have lib/libcrypto.so.1.0.0 based on the > > glibc ldd output below. > No, that ldd was run inside, pure, chrooted musl environment. No glibc > inside. this does not matter > These are the only libcrypto* files inside that chroot environment: > > ls -lah /usr/lib/libcrypto.* > -rw-r--r-- 1 0 0 5.0M Dec 17 00:24 /usr/lib/libcrypto.a > lrwxrwxrwx 1 0 0 16 Dec 17 00:24 > /usr/lib/libcrypto.so -> libcrypto.so.1.1 > -rwxr-xr-x 1 0 0 3.0M Jan 26 12:58 > /usr/lib/libcrypto.so.1.1 > like i said, you linked the wrong library, try to link the right one. again, if you run the ldso under strace the problem will be obvious and we dont have to waste time. you should also strace ld to see what gets linked, if it's /usr/lib/libcrypto... then that's wrong. (instead of strace you can use -Wl,--trace) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 2018-01-27 19:26 ` Szabolcs Nagy @ 2018-01-27 22:07 ` Stefan Fröberg 2018-01-28 0:54 ` Szabolcs Nagy 0 siblings, 1 reply; 14+ messages in thread From: Stefan Fröberg @ 2018-01-27 22:07 UTC (permalink / raw) To: Szabolcs Nagy; +Cc: musl Hi Here is the strace strace ./x execve("./x", ["./x"], 0x7ffc8a938740 /* 20 vars */) = 0 arch_prctl(ARCH_SET_FS, 0x7fb0d02cfba8) = 0 set_tid_address(0x7fb0d02cfbe0) = 2954 readlink("/proc/self/exe", "/root/batman/x", 512) = 14 open("/root/batman/lib/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fstat(3, {st_mode=S_IFREG|0755, st_size=2800952, ...}) = 0 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\220\6\0\0\0\0\0"..., 960) = 960 mmap(NULL, 4911104, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7fb0cfb92000 mmap(0x7fb0d0016000, 176128, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x284000) = 0x7fb0d0016000 mmap(0x7fb0d003e000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb0d003e000 close(3) = 0 mprotect(0x7fb0d0016000, 122880, PROT_READ) = 0 mprotect(0x7fb0d02cc000, 4096, PROT_READ) = 0 mprotect(0x5574fa625000, 4096, PROT_READ) = 0 ioctl(1, TIOCGWINSZ, {ws_row=34, ws_col=107, ws_xpixel=1284, ws_ypixel=748}) = 0 writev(1, [{iov_base="Initializing crypto ... OK", iov_len=26}, {iov_base="\n", iov_len=1}], 2Initializing crypto ... OK ) = 27 exit_group(0) = ? +++ exited with 0 +++ ./x Initializing crypto ... OK So it find and uses the correct, local version $ORIGIN/lib (/root/batman/lib/libcrypto.so.1.1) of libcrypto.so.1.1 and "readelf -d x" confirms it. But for some reason ldd does not show it. ldd x /lib/ld-musl-x86_64.so.1 (0x7f22efa03000) libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x7f22ef352000) libc.so => /lib/ld-musl-x86_64.so.1 (0x7f22efa03000) ******************************************************************** #include <stdio.h> #include <openssl/ssl.h> int main(void) { printf("Initializing crypto ... "); int r = OPENSSL_init_crypto(OPENSSL_INIT_NO_ADD_ALL_CIPHERS|OPENSSL_INIT_NO_ADD_ALL_DIGESTS,NULL); printf("%s\n",(r == 1 ? "OK" : "FAILED")); return(0); } ********************************************************************* readelf -d x Dynamic section at offset 0xe10 contains 24 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so] 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/lib] 0x000000000000000c (INIT) 0x608 0x000000000000000d (FINI) 0x8e2 0x000000006ffffef5 (GNU_HASH) 0x220 0x0000000000000005 (STRTAB) 0x3c0 0x0000000000000006 (SYMTAB) 0x258 0x000000000000000a (STRSZ) 253 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0x201000 0x0000000000000002 (PLTRELSZ) 96 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x5a8 0x0000000000000007 (RELA) 0x500 0x0000000000000008 (RELASZ) 168 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffb (FLAGS_1) Flags: PIE 0x000000006ffffffe (VERNEED) 0x4e0 0x000000006fffffff (VERNEEDNUM) 1 0x000000006ffffff0 (VERSYM) 0x4be 0x000000006ffffff9 (RELACOUNT) 2 0x0000000000000000 (NULL) 0x0 Szabolcs Nagy kirjoitti 27.01.2018 klo 21:26: > * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-27 18:20:27 +0200]: >> Szabolcs Nagy kirjoitti 27.01.2018 klo 13:07: >>> * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-27 01:50:21 +0200]: >>>> My ldd is just symbolic link inside musl chroot environment, to >>>> /lib/ld-musl-x86_64.so.1 >>>> and it's symbolic link to /lib/libc.so >>>> >>>> Here is readelf output of that test program >>>> readelf -d x >>>> >>>> Dynamic section at offset 0xe10 contains 24 entries: >>>> Tag Type Name/Value >>>> 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1] >>> ^^^^^^^^^^^^^^^^ >>> this looks like the wrong library version >>> >>> if you had straced the ldd output you would have seen >>> that musl tries to open lib/libcrypto.so.1.1, but you >>> probably only have lib/libcrypto.so.1.0.0 based on the >>> glibc ldd output below. >> No, that ldd was run inside, pure, chrooted musl environment. No glibc >> inside. > this does not matter > >> These are the only libcrypto* files inside that chroot environment: >> >> ls -lah /usr/lib/libcrypto.* >> -rw-r--r-- 1 0 0 5.0M Dec 17 00:24 /usr/lib/libcrypto.a >> lrwxrwxrwx 1 0 0 16 Dec 17 00:24 >> /usr/lib/libcrypto.so -> libcrypto.so.1.1 >> -rwxr-xr-x 1 0 0 3.0M Jan 26 12:58 >> /usr/lib/libcrypto.so.1.1 >> > like i said, you linked the wrong library, try to link > the right one. again, if you run the ldso under strace > the problem will be obvious and we dont have to waste time. > > you should also strace ld to see what gets linked, > if it's /usr/lib/libcrypto... then that's wrong. > (instead of strace you can use -Wl,--trace) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 2018-01-27 22:07 ` Stefan Fröberg @ 2018-01-28 0:54 ` Szabolcs Nagy 2018-02-07 17:35 ` Rich Felker 0 siblings, 1 reply; 14+ messages in thread From: Szabolcs Nagy @ 2018-01-28 0:54 UTC (permalink / raw) To: Stefan Fröberg; +Cc: musl * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-28 00:07:33 +0200]: > strace ./x ... > open("/root/batman/lib/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3 ... > ldd x > /lib/ld-musl-x86_64.so.1 (0x7f22efa03000) > libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x7f22ef352000) > libc.so => /lib/ld-musl-x86_64.so.1 (0x7f22efa03000) this is a bug in musl ldd: if the executable path has no / then it assumes origin is /, try ldd ./x then origin is ./ so it works as expected. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 2018-01-28 0:54 ` Szabolcs Nagy @ 2018-02-07 17:35 ` Rich Felker 2018-02-07 20:28 ` Szabolcs Nagy 0 siblings, 1 reply; 14+ messages in thread From: Rich Felker @ 2018-02-07 17:35 UTC (permalink / raw) To: musl; +Cc: Stefan Fröberg [-- Attachment #1: Type: text/plain, Size: 903 bytes --] On Sun, Jan 28, 2018 at 01:54:25AM +0100, Szabolcs Nagy wrote: > * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-28 00:07:33 +0200]: > > strace ./x > ... > > open("/root/batman/lib/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3 > ... > > ldd x > > /lib/ld-musl-x86_64.so.1 (0x7f22efa03000) > > libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x7f22ef352000) > > libc.so => /lib/ld-musl-x86_64.so.1 (0x7f22efa03000) > > this is a bug in musl ldd: if the executable > path has no / then it assumes origin is /, try > > ldd ./x > > then origin is ./ so it works as expected. Does the attached patch look ok? Alternatively we could fix the assumed invariant that p->name always contains a slash by having the loader code in __dls3 allocate a copy of argv[0] with "./" prepended, but that's a heavier cost at runtime and doesn't seem to have any practical advantages. Rich [-- Attachment #2: ldd-curdir.diff --] [-- Type: text/plain, Size: 435 bytes --] diff --git a/ldso/dynlink.c b/ldso/dynlink.c index 3380240..f507bc4 100644 --- a/ldso/dynlink.c +++ b/ldso/dynlink.c @@ -807,7 +807,12 @@ static int fixup_rpath(struct dso *p, char *buf, size_t buf_size) origin = p->name; } t = strrchr(origin, '/'); - l = t ? t-origin : 0; + if (t) { + l = t-origin; + } else { + origin = "."; + l = 1; + } p->rpath = malloc(strlen(p->rpath_orig) + n*l + 1); if (!p->rpath) return -1; ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 2018-02-07 17:35 ` Rich Felker @ 2018-02-07 20:28 ` Szabolcs Nagy 0 siblings, 0 replies; 14+ messages in thread From: Szabolcs Nagy @ 2018-02-07 20:28 UTC (permalink / raw) To: musl; +Cc: Stefan Fröberg * Rich Felker <dalias@libc.org> [2018-02-07 12:35:31 -0500]: > On Sun, Jan 28, 2018 at 01:54:25AM +0100, Szabolcs Nagy wrote: > > * Stefan Fröberg <stefan.froberg@petroprogram.com> [2018-01-28 00:07:33 +0200]: > > > strace ./x > > ... > > > open("/root/batman/lib/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3 > > ... > > > ldd x > > > /lib/ld-musl-x86_64.so.1 (0x7f22efa03000) > > > libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x7f22ef352000) > > > libc.so => /lib/ld-musl-x86_64.so.1 (0x7f22efa03000) > > > > this is a bug in musl ldd: if the executable > > path has no / then it assumes origin is /, try > > > > ldd ./x > > > > then origin is ./ so it works as expected. > > Does the attached patch look ok? > looks good. > Alternatively we could fix the assumed invariant that p->name always > contains a slash by having the loader code in __dls3 allocate a copy > of argv[0] with "./" prepended, but that's a heavier cost at runtime > and doesn't seem to have any practical advantages. > > Rich > diff --git a/ldso/dynlink.c b/ldso/dynlink.c > index 3380240..f507bc4 100644 > --- a/ldso/dynlink.c > +++ b/ldso/dynlink.c > @@ -807,7 +807,12 @@ static int fixup_rpath(struct dso *p, char *buf, size_t buf_size) > origin = p->name; > } > t = strrchr(origin, '/'); > - l = t ? t-origin : 0; > + if (t) { > + l = t-origin; > + } else { > + origin = "."; > + l = 1; > + } > p->rpath = malloc(strlen(p->rpath_orig) + n*l + 1); > if (!p->rpath) return -1; > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 2018-01-26 13:39 BUG: $ORIGIN does not seem to work Stefan Fröberg 2018-01-26 14:21 ` Szabolcs Nagy @ 2018-01-26 16:34 ` Rich Felker 2018-01-26 21:28 ` Stefan Fröberg 1 sibling, 1 reply; 14+ messages in thread From: Rich Felker @ 2018-01-26 16:34 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: BUG: $ORIGIN does not seem to work 2018-01-26 16:34 ` Rich Felker @ 2018-01-26 21:28 ` Stefan Fröberg 0 siblings, 0 replies; 14+ messages in thread From: Stefan Fröberg @ 2018-01-26 21:28 UTC (permalink / raw) To: Rich Felker; +Cc: musl 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-02-07 20:28 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-26 13:39 BUG: $ORIGIN does not seem to work 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
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).