Re: dlsym(handle) may search in unrelated libraries

[Markus Wichmann <nullplan@gmx.net>]

On Thu, Feb 07, 2019 at 01:57:36PM -0500, Rich Felker wrote:
> Yes. GCC has an extension for ctor priority within static linking
> scope, but for dynamic linking scope that doesn't help. I don't like
> any of this but glib depends on it to avoid just doing the right thing
> with pthread_once/call_once, and refuses to fix it.
> 

Well, at least we are on the same page, here. And my opinion of glib is
validated once more. Unfortunately, at this point it is too big to fail,
in several ways.

> Yes, but you can also avoid recursion just by looping to the deepest
> dependency with !inited, then going back to the root. For a one-time
> operation at dlopen-time or program-start time, the quadratic search
> for each !inited seems unlikely to be a problem:
> 

Wait, I have an idea. If the only ordering is that the dependencies need
to be initialized before their dependents, then couldn't we just
initialize the libs in reverse BFS order? The elements further down the
tree are all necessarily further down the list, aren't they?

> I don't follow. The dlopen operation is not committed until load of
> all dependencies completes successfully, and if any fail to load, the
> whole operation is backed-out. But ctors don't/can't run until *after*
> that, when we've already committed to success.
> 

That is true for the runtime case, i.e. dlopen(). But load_deps() is
also called at load time. And initializers have to run at load time,
too. And in the correct order.

If at load time, any dependencies fail to load, an error message is
printed and then the loop continues. load_deps() has no way to signal
failure to the caller, and at load time it will not exit the function in
another way, i.e. longjump (which is good since that would be invalid at
that time). So by the time the initializers are called, all dependencies
are loaded except those which failed.

> Rich

Ciao,
Markus