Re: dlsym(handle) may search in unrelated libraries

[Rich Felker <dalias@libc.org>]

On Fri, Feb 08, 2019 at 01:00:16PM +0100, Szabolcs Nagy wrote:
> * A. Wilcox <awilfox@adelielinux.org> [2019-02-08 04:19:32 -0600]:
> > On Feb 7, 2019, at 10:54 AM, Rich Felker <dalias@libc.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