[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a11d2224-cc3f-1731-6a40-c99e07a63239@samersoff.net>
Date: Wed, 27 May 2020 21:10:18 +0300
From: Dmitry Samersoff <dms@...ersoff.net>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
Alexander Scherbatiy <alexander.scherbatiy@...l-sw.com>
Cc: Markus Wichmann <nullplan@....net>
Subject: Re: 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
>
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.
