[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190208160934.GV23599@brightrain.aerifal.cx>
Date: Fri, 8 Feb 2019 11:09:34 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: dlsym(handle) may search in unrelated libraries
On Fri, Feb 08, 2019 at 01:00:16PM +0100, Szabolcs Nagy wrote:
> * A. Wilcox <awilfox@...lielinux.org> [2019-02-08 04:19:32 -0600]:
> > On Feb 7, 2019, at 10:54 AM, Rich Felker <dalias@...c.org> 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
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.
