[Bug dynamic-link/14379] shared object constructors are called in the wrong order

[luto at kernel dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14379

--- Comment #13 from Andy Lutomirski <luto at kernel dot org> ---
(In reply to Rich Felker from comment #12)
> Are you saying it would suffice for your needs just to reverse the order of
> sibling ctor execution, so that earlier (in load order/symbol definition
> order) dependencies of the same parent get constructed before later ones,
> with all the (direct) preloads being ordered as if they were early
> DT_NEEDEDs of the main program? That seems reasonable to me, and I think it
> matches the newly introduced behavior in musl (I just pushed changes doing
> real topological dep order for ctors), which isn't really intentional in
> that regard but just the most natural fallout of the topological sort.
> 

It would, and I think that behavior would make a lot more sense.

> I still think your original usage case is highly broken though. A malloc
> implementation should be prepared to be called before any particular ctor
> has executed. If glibc documents requirements for safety of an interposed
> malloc replacement at some point, I think this should be considered for
> making a documented requirement.

Indeed, and I fixed that.  I was just very surprised when I found out that the
reason my library didn't work without this change was that glibc called the
ctor much later than seemed reasonable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.