From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12413 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Stefan_Fr=c3=b6berg?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: BUG: $ORIGIN does not seem to work Date: Sat, 27 Jan 2018 18:20:27 +0200 Message-ID: References: <17b31628-04b5-3181-4623-046ffc4c0cab@petroprogram.com> <20180126142137.GH4418@port70.net> <20180127110722.GI4418@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1517070094 8378 195.159.176.226 (27 Jan 2018 16:21:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 Jan 2018 16:21:34 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Cc: musl@lists.openwall.com To: Szabolcs Nagy Original-X-From: musl-return-12429-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jan 27 17:21:30 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1efTEE-0001Cv-Cp for gllmg-musl@m.gmane.org; Sat, 27 Jan 2018 17:21:18 +0100 Original-Received: (qmail 18316 invoked by uid 550); 27 Jan 2018 16:23:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 18282 invoked from network); 27 Jan 2018 16:23:18 -0000 In-Reply-To: <20180127110722.GI4418@port70.net> Content-Language: en-US Xref: news.gmane.org gmane.linux.lib.musl.general:12413 Archived-At: Hi Szabolcs Nagy kirjoitti 27.01.2018 klo 13:07: > * Stefan Fröberg [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 [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)