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 22355 invoked from network); 28 May 2020 18:53:41 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 28 May 2020 18:53:41 -0000 Received: (qmail 28554 invoked by uid 550); 28 May 2020 18:53:37 -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 28533 invoked from network); 28 May 2020 18:53:37 -0000 Date: Thu, 28 May 2020 20:53:25 +0200 From: Szabolcs Nagy To: Dmitry Samersoff Cc: musl@lists.openwall.com, Rich Felker , Alexander Scherbatiy , Markus Wichmann Message-ID: <20200528185325.GF26190@port70.net> Mail-Followup-To: Dmitry Samersoff , musl@lists.openwall.com, Rich Felker , Alexander Scherbatiy , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [musl] Shared library loading * Dmitry Samersoff [2020-05-27 21:10:18 +0300]: > 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 this step sounds like implementation specific heuristic that is not mandated by any spec, so relying on it is non-portable (and in this case can be dangerous: an unrelated library may be used because of a name collision) in principle a dynamic linker can continue even if it didn't find a library with similar name at all, but that would be dangerous too. > > 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 think if there is no spec you should not rely on this behaviour, i.e. it is a portability bug.