This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: wrong (?) order of initialization of so.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Andrea <mariofutire at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Mon, 6 Jan 2014 23:39:42 +0100
- Subject: Re: wrong (?) order of initialization of so.
- Authentication-results: sourceware.org; auth=none
- References: <52CB2386 dot 1000002 at gmail dot com>
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