Subject: Re: libpthread and static constructor order
To: None <tech-userlevel@NetBSD.org>
From: J.T. Conklin <firstname.lastname@example.org>
Date: 11/08/2007 14:44:38
email@example.com (J.T. Conklin) writes:
>> Note that what I said above is how it *should* behave. From reading
>> ld.elf_so I am not sure whether it is actually doing that. Can you check
>> in which order the DT_NEEDED entries are in the binary? I think the part
>> about resorting the order list is not done at all...
> I see that rtld.c has a _rtld_dag_init() to initialize a DAG from the
> objects. Could the fix be as simple as initializing the DAG (this is
> currently only done for dlopen()ed libraries), and then walking the DAG
> instead of the list for the init/fini routines?
Ok, it was a bit more complicated than that, especially handing edge
cases such as linking with a a shared library whose ctors and dtors
dlopen() and dlclose() another shared library that depends on yet
another shared library that also happens to be linked to the main
executable. One unit test I wrote for this even found a case where
the Solaris 10 ld.so initializes a dlopened() shared library before
I did this for an old NetBSD-3-ish -current. I'll submit a PR once
I adapt it for NetBSD 4/-current.