Date: Thu, 28 May 2020 20:53:25 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: Dmitry Samersoff <dms@...ersoff.net> Cc: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>, Alexander Scherbatiy <alexander.scherbatiy@...l-sw.com>, Markus Wichmann <nullplan@....net> Subject: Re: Shared library loading * Dmitry Samersoff <dms@...ersoff.net> [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.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.