From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13733 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: dlsym(handle) may search in unrelated libraries Date: Fri, 8 Feb 2019 11:09:34 -0500 Message-ID: <20190208160934.GV23599@brightrain.aerifal.cx> References: <20190206160248.GB5469@voyager> <20190206202518.GC5469@voyager> <96c367533236e3e203f04a994ee65c47@ispras.ru> <20190207053327.GD5469@voyager> <20190207165447.GP23599@brightrain.aerifal.cx> <4B0996EC-3EE5-438E-8BFA-245644408109@adelielinux.org> <20190208120016.GM21289@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="202814"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13749-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 08 17:09:51 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gs8is-000qe3-4Q for gllmg-musl@m.gmane.org; Fri, 08 Feb 2019 17:09:50 +0100 Original-Received: (qmail 24338 invoked by uid 550); 8 Feb 2019 16:09:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 24318 invoked from network); 8 Feb 2019 16:09:47 -0000 Content-Disposition: inline In-Reply-To: <20190208120016.GM21289@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13733 Archived-At: On Fri, Feb 08, 2019 at 01:00:16PM +0100, Szabolcs Nagy wrote: > * A. Wilcox [2019-02-08 04:19:32 -0600]: > > On Feb 7, 2019, at 10:54 AM, Rich Felker wrote: > > > > > > However, a depth-first list of dependencies is also needed to solve the longstanding ctor-order issue discussed in several past threads (which I can look up if search doesn't turn them up for you). This is not a requirement of POSIX (which doesn't even have ctors), but it's a reasonable expectation we currently get wrong and I think it might be specified in ELF or some related sysv "standards". > > > > > > It is part of the ELF 1.2 standard and is not only required by GLib, but also Nouveau, gtk-doc, some Qt apps, and others. > > note, that the ctor order in c++ is undefined across translation > units so if a c++ application relies on it that's a bug: the c++ > ctor concept does not necessarily map directly to the elf > initialization function concept on an elf platform so the elf > spec does not save them. In this case they're not using C++ but the GNU C extension. > in the elf context, relying on DT_NEEDED for ctor ordering > across libraries means that static linking is broken since > then there is no DT_NEEDED. This is true, but they can make static linking also work (within libraries that share a convention on the priority values to use) by using the GNU C ctor priority attributes. This could fix the glib bug. I forget if any distros are doing it out-of-tree or if they just patched the one ctor to call the other init function explicitly. > so these packages should be fixed independently of musl > (assuming they want to be portable or at least static linkable). This is probably mostly correct. > that said, lot of libraries do rely on dependency based ctor > ordering even beyond the elf guarantees (glibc and solaris > dynamic linkers considers relocations on top of DT_NEEDED to > establish dependencies between dsos) and some applications > have dependency cycles which of course is impossible to get > right but glibc tries to keep the ctor order deterministic > in some way even in the presence of dlopen during init. > > originally dynamic linkers did exactly what musl did, there > is a nice overview how the complexity evolved: > https://blogs.oracle.com/solaris/init-and-fini-processing-who-designed-this-v2 Good to know there's precedent. Rich