wrong (?) order of initialization of so.

Ondřej Bílka neleai@seznam.cz
Mon Jan 6 22:39:00 GMT 2014


On Mon, Jan 06, 2014 at 09:43:34PM +0000, Andrea wrote:
> Hi,
> 
> I would like to ask for help for a problem I have been having recently.
> On RHEL 5 (and 4) I get the feeling the some .so in my projects are initialized in the wrong order.
> This does not happen always, it depends on how many other .so are loaded.
> It never happens in Fedora 19.
> 
> The whole project has many (~50) .so, but I seem to have tracked down the issue to 4 of them
> 
> A depends on B
> B depends on C, D
> C depends on D
> 
> these dependencies are used when linking and when I inspect the .so with readelf -d I can see
> exactly these listed as DT_NEEDED (+ others 3rd party libraries)
> 
> Then doing LD_DEBUG=libs I can see that the order of initialization of these 4 is
> 
> D, B, then seg fault (as B really needs C to be initialized first).
> 
> When it works, the order is
> D, C, B, A
> (which is the only valid order as far as I can tell).
> 
> I am not too sure who decides this order (the kernel? gcc? ld? libc?).
> Since it has never happened on Fedora 19, I am inclined to blame some old bug in RHEL 5
> (running linux 2.6.18 and libc 2.5).
> 
> Does it ring a bell to anybody? How could I check I have not messed up things in the build process?
> Does it exists a way to debug that?
> 
The ld decides order and it should be A B C D. Simplest explanation would be cyclic dependecy,
is there E that D depend on C and E depends on A?

If not then you could try reproduce layout by compiling dummy libraries
with same layout like

gcc dummy.c -L. -lC -lD -fPIC -shared -o libB.so



More information about the Libc-help mailing list