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=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30738 invoked from network); 27 May 2020 18:10:53 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 May 2020 18:10:53 -0000 Received: (qmail 20116 invoked by uid 550); 27 May 2020 18:10:50 -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 20098 invoked from network); 27 May 2020 18:10:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samersoff.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:Cc:To:Subject:From:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1qLVQhNc7FwxYMuy6d08iHBENxJIuhFXugFZ5P6oWsU=; b=XuKdBW4+PzM2HaI+y3MRnMN7uY S609eAc00x0BkzepSJklqQgwLDdwkBvhrvPN7GWE886RNge0AwfuN0TbNZjXkl+FMSwDdlY+LHUTw VhlNldSCCNDjwhHcGpPif6YqwvXu/2bSq9LCZ7vFdWTbRLflIjpn2L01tUHiXkWAPbR8=; From: Dmitry Samersoff To: musl@lists.openwall.com, Rich Felker , Alexander Scherbatiy Cc: Markus Wichmann References: <20200521152121.GA6521@voyager> <883535a2-1b26-183d-22f4-c3c158da2dbb@bell-sw.com> <20200522182555.GA1079@brightrain.aerifal.cx> <96367f9c-4b02-c512-9d46-96de9e39a059@bell-sw.com> <20200525174633.GA31470@brightrain.aerifal.cx> Message-ID: Date: Wed, 27 May 2020 21:10:18 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200525174633.GA31470@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As: dms X-SpamProbe: GOOD 0.0000147 9cebaa9851110dc696e8f8d4eb26e5f3 Subject: Re: [musl] Shared library loading Hello Alexander, > The "b" library loading works on my Ubuntu 19.10 and > fails on Alpine 3.11.6 with message: > dlopen failed: Error loading shared library liba.so: No such file or > directory (needed by /root/load-lib-sample/bin/b/libb.so) > Should it work on Alpine with musl libc as well? 1. You explicitly load library with a path (.../liba.so) 2. You are explicitly loading another library (.../libb.so) 3. Linker find liba.so in the appropriate section of libb.so and attempts to load it from syspath (LD_LIBRARY_PATH etc) 4. Linker doesn't find it. Musl return error on this step but glibc and BSD go further. 5. Linker compares short names of already loaded library and the required one 6. It matches, so Linker decides to resolve I didn't find any specification that dictates one or other behavior, so it could not be considered as a bug. -Dmitry On 25.05.2020 20:46, Rich Felker wrote: > On Mon, May 25, 2020 at 08:26:51PM +0300, Alexander Scherbatiy wrote: >> On 22.05.2020 21:25, Rich Felker wrote: >> >>> The concept here is that non-pathname library names should be loaded >> >from the library path and not replaced by something (typically a >>> "module" or "plug-in") in a different, explicitly-loaded location that >>> happens to have a colliding base filename. >>> >>> For example suppose your application loads modules from $libdir/myapp/ >>> and has a module named "libfoo.so". Unbeknownst to you, there's also a >>> "libfoo.so" in the system paths, and some library you potentially load >>> indirectly (maybe the GPU driver for some video hardware you've never >>> heard of) depends on "libfoo.so". >>> >>> If dlopen("$libdir/myapp/libfoo.so") had put "libfoo.so" in the >>> namespace such that it would satisfy future load requests for the name >>> "libfoo.so", the subsequent load would break due to getting the wrong >>> (unrelated) library. >>   Is it correct that RTLD_GLOBAL flag is in some kind of obsolete in >> musl because calling >>     dlopen("$libdir/myapp/libfoo.so", RTLD_NOW | RTLD_GLOBAL); >>     dlopen("$libdir2/myapp2/libbar.so", RTLD_LAZY); >> >>    does not allow libbar.so to find library $libdir/myapp/libfoo.so >> which it is depend on? > > This is not what RTLD_GLOBAL means. RTLD_GLOBAL is a matter of whether > the library's symbols appear in the global symbol namespace to resolve > relocations in future-loaded libraries and dlsym with RTLD_DEFAULT. It > has nothing to do with whether the library is visible for satisfying > DT_NEEDED. The library is *always* visible for this purpose. > >>   What is the suggested way in musl to load $libdir/myapp/libfoo.so >> from a custom directory so libbar.so can find it? > > Probably putting the dir in your application's rpath (or in the rpath > of libbar). dlopen is not a tool for (effectively) adding additional > directories to the library search path. > > Rich >