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.3 required=5.0 tests=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 26136 invoked from network); 28 May 2020 19:29:37 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 28 May 2020 19:29:37 -0000 Received: (qmail 23838 invoked by uid 550); 28 May 2020 19:29:36 -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 23816 invoked from network); 28 May 2020 19:29:34 -0000 Date: Thu, 28 May 2020 15:29:22 -0400 From: Rich Felker To: Jeffrey Walton Cc: musl@lists.openwall.com Message-ID: <20200528192922.GE1079@brightrain.aerifal.cx> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Shared library loading On Thu, May 28, 2020 at 03:20:46PM -0400, Jeffrey Walton wrote: > On Wed, May 27, 2020 at 2:10 PM Dmitry Samersoff wrote: > > > > > 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. > > I believe Drepper's DSO HowTo specifies the behavior for Linux. > > Also see https://www.akkadia.org/drepper/dsohowto.pdf. I'm not sure if the further search of already loaded libraries is harmful or not, but Drepper's spec is not a standard we implement in musl. It's certainly open to discussion but it's the type of behavior that can easily have unforseen and bad consequences, and I would not want to be hasty/sloppy about adopting it. Rich