Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 28 May 2020 20:53:25 +0200
From: Szabolcs Nagy <>
To: Dmitry Samersoff <>
Cc:, Rich Felker <>,
	Alexander Scherbatiy <>,
	Markus Wichmann <>
Subject: Re: 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
> > No such file or
> > directory (needed by /root/load-lib-sample/bin/b/
> > Should it work on Alpine with musl libc as well?
> 1. You explicitly load library with a path (.../
> 2. You are explicitly loading another library (.../
> 3. Linker find in the appropriate section of 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.