This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Has dlopen() behaviour changed between libc 4.1 and libc 4.4?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: David Aldrich <David dot Aldrich at EMEA dot NEC dot COM>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Mon, 13 May 2013 17:49:28 +0200
- Subject: Re: Has dlopen() behaviour changed between libc 4.1 and libc 4.4?
- References: <41302A7145AC054FA7A96CFD03835A0A0B72B3F9 at EX10MBX02 dot EU dot NEC dot COM>
On Mon, May 13, 2013 at 02:33:45PM +0000, David Aldrich wrote:
> Now, this code runs fine when built with gcc 4.1 on Centos 5. We always succeed in loading all required libraries after a few passes through the while loop. But when we build and run it with gcc 4.4.7 on Centos 6, a certain library always fails to load. This is repeatable. Here's the behaviour:
>
> If our list contains libA, libB, libC, libD, libE, the trace output shows:
>
> PASS 1
> Attempting to load file libA
> Loading libA
> Attempting to load file libB
> Failed to load libB
> Attempting to load file libC
> Loading libC
> Attempting to load file libD
> Failed to load libD
> Attempting to load file libE
> Failed to load libE
>
> PASS 2
> Attempting to load file libB
> Loading libB
> Attempting to load file libD
> < dlopen( ..., RTLD_NOLOAD) returns a handle - i.e. it thinks library D is already loaded, so we don't try to load it >
> Attempting to load file libE Loading libC
>
> So the code thinks that all the libraries loaded, but actually libD never got loaded. On the first pass LibD failed to load, but on the second pass the code believes the libD is already loaded and doesn't try to load it again.
>
> It is odd that this changed behaviour is associated with moving from gcc 4.1 to gcc 4.4. I am told that this behaviour change is more likely to be associated with libc than with gcc, so I posted to this list.
>
> Please can anyone suggest a fix for this problem?
>
Could you provide simple makefile which compiles libraries
libA,... with dependecies that lead to this behaviour?
to get your behaviour? We cannot help without that data.