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 24046 invoked from network); 25 May 2020 17:46:50 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 25 May 2020 17:46:50 -0000 Received: (qmail 17629 invoked by uid 550); 25 May 2020 17:46:46 -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 17608 invoked from network); 25 May 2020 17:46:46 -0000 Date: Mon, 25 May 2020 13:46:33 -0400 From: Rich Felker To: Alexander Scherbatiy Cc: musl@lists.openwall.com, Markus Wichmann Message-ID: <20200525174633.GA31470@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <96367f9c-4b02-c512-9d46-96de9e39a059@bell-sw.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Shared library loading 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