dlopen deadlock

[Szabolcs Nagy <nsz@port70.net>]

This bug i reported against glibc also affects musl:
https://sourceware.org/bugzilla/show_bug.cgi?id=19448

in case of musl it's not the global load lock, but the
init_fini_lock that causes the problem.

the multi-threadedness detection is also problematic in
do_init_fini:

	need_locking = has_threads
	if (need_locking)
		lock(init_fini_lock)
	for all deps
		run_ctors(dep)
		if (!need_locking && has_threads)
			need_locking = 1
			lock(init_fini_lock)
	if (need_locking)
		unlock(init_fini_lock)

checking for threads after ctors are run is too late if
the ctors may start new threads that can dlopen libs with
common deps with the currently loaded lib.

one solution i can think of is to have an init_fini_lock
for each dso, then the deadlock only happens if a ctor
tries to dlopen its own lib (directly or indirectly)
which is nonsense (the library depends on itself being
loaded)

(in glibc with a self-loading ctor in the same thread the
second dlopen succeeds even though the ctors haven't finished
running, not sure if that's better than deadlock, in any case
running user code from libc is problematic, ctors vs dlopen
seems to be a disaster)