From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26642 invoked from network); 20 Apr 2022 16:04:07 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Apr 2022 16:04:07 -0000 Received: (qmail 21870 invoked by uid 550); 20 Apr 2022 16:04:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 21835 invoked from network); 20 Apr 2022 16:04:05 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 20 Apr 2022 18:03:49 +0200 From: Kai Peter To: musl@lists.openwall.com In-Reply-To: <20220420131236.GB7074@brightrain.aerifal.cx> References: <20220420131236.GB7074@brightrain.aerifal.cx> Message-ID: <16781046206c091d64ff4928d793250a@lists.qware.org> X-Sender: kp@lists.qware.org User-Agent: Roundcube Webmail/1.3.2 Subject: Re: [musl] Search path for shared libs On 2022-04-20 15:12, Rich Felker wrote: > On Wed, Apr 20, 2022 at 09:15:43AM +0200, Kai Peter wrote: >> Hi, >> >> I did run in an issue with the search path of shared objects. I'm on >> a real custom system, so the pathes below are correct. There is no >> glibc at all, the gcc was modified to build with the loader in >> /qlnx/lib. curl was build with shared openssl libs as a dependency >> for git. Then I issue >> >> $ ldd /misc/bin/curl >> /qlnx/lib/ld-musl-x86_64.so.1 (0x7f1e1df97000) >> libcurl.so.4 => /misc/lib/libcurl.so.4 (0x7f1e1df0f000) >> libssl.so.1.1 => /libs/lib/libssl.so.1.1 (0x7f1e1de79000) >> libcrypto.so.1.1 => /libs/lib/libcrypto.so.1.1 >> (0x7f1e1dbb0000) >> libz.so.1 => /qlnx/lib/libz.so.1 (0x7f1e1db93000) >> libc.so => /qlnx/lib/ld-musl-x86_64.so.1 (0x7f1e1df97000) >> libzstd.so.1 => /qlnx/lib/libzstd.so.1 (0x7f1e1da81000) >> >> All fine, pathes are correct and working. Then: >> >> $ ldd /misc/lib/libcurl.so.4 2>&1 | grep -v reloc >> ldd (0x7f122b691000) >> Error loading shared library libssl.so.1.1: No such file or >> directory (needed by /misc/lib/libcurl.so.4) >> Error loading shared library libcrypto.so.1.1: No such file or >> directory (needed by /misc/lib/libcurl.so.4) >> libzstd.so.1 => /qlnx/lib/libzstd.so.1 (0x7f122b4f7000) >> libz.so.1 => /qlnx/lib/libz.so.1 (0x7f122b4da000) >> libc.so => ldd (0x7f122b691000) >> >> As a workaround I can create symlinks of the missing ssl libs in >> /qlnx/lib. The ld-musl-x86_64.path contains all pathes and it is >> read. So the question is: Why does libcurl.so.4 not find >> libssl/libcrypto? Any insight? > > Is the ldd you're invoking a symlink to ldso? If so, that's deprecated > usage which has problems using the right path (because the pathname > comes from what was used to invoke ldd) and you should replace it with > a shell script: > > #!/bin/sh > exec /qlnx/lib/ld-musl-x86_64.so.1 --list "$@" > > Then ldso will have the right base pathname to look for its .path file > relative to. Hi, ldd is a symlink to ../lib/ld-musl-x86_64.so.1. However, I found a solution in another thread (where I accidentally replied to). I did remember that I changed the sys_path in dynlink.c. At this time I didn't know all lib pathes. I did add the missing ones and all is working fine for me. The root cause was that libcurl was used by git and didn't find libssl. This is working now. As suggested I have replaced the link with the script too. Kai