Changes made to gcc 4.5 regarding binding?

Question

I have a project that creates a shared library associated with another, also a shared library.

When I compile and link it with gcc 4.4, everything works:

• Missing warning or compile time error,
• There is no warning or connection time error and
• ldd libmyproject.so correctly reports a dependency with another shared library.

When I compile and link it to gcc 4.5, on the other hand (with the same flags), I have the following symptoms:

• Missing warning or compile time error,
• Missing warning or binding time error, but
• the library is incorrectly linked to another shared library: this manifest itself when I start ldd and I don’t see the connection, and also when I try to use it: while it works with gcc 4.4, it crashes at runtime with gcc 4.5 with the error "character was not found "(of course, from another library).

I watched the release notes , and my intuition is that it has something to do with the new optimization of link time, but I could not understand them in sufficient detail.

Has anyone encountered a similar situation and / or offered any recommendations?

(Note that the results from 4.6 look identical to 4.5).

Answer 1

To summarize Mat's answer from GCC 4.5 against 4.4 dependency links and discussion in the comments, you need to link:

 --copy-dt-needed-entries and --no-as-needed 

Answer 2

You can debug a dynamically linked application with the environment variable LD_DEBUG. This is the ld-linux.so.2 ; ldd is a script to set such an option. All parameters are described on the page http://linux.die.net/man/8/ld-linux .

How to use LD_DEBUG (in bash; the easiest way):

  $ LD_DEBUG=all ./your_program 

This will debug the ld-linux.so.2 dynamic linker at runtime. It will print a lot of debugging in stdout or stderr and you can

• 1) Compare the output of " LD_DEBUG=all ./your_program_4.4 " and " LD_DEBUG=all ./your_program_4.5 "
• 2) see the last characters to be eliminated and find the buggy symbol.

In addition, you must provide us with additional information:

• 0) What is your OS and type of cpu? (show us the output of uname -a ) What is the version of libc? (run bash for a in /lib*/libc.so.*;do echo $a; $a; done )
• 1) What do the flags of your library collect?
• 2) What is the exact error when trying to run the application?
• 3) The last lines from the output of LD_DEBUG may contain valuable information

UPDATE: Good and accurate answer here: GCC 4.5 vs 4.4, related to dependencies (by Mat)

Answer 3

Make sure you specify your shared libraries after the object (or source) files on the linker command line.

So you had to do this with static libraries in the old days. It seems like it is profitable again with the latest versions of GCC. As far as I can tell, if it scans a shared library that does not provide any useful characters, it ignores the whole library, which optimizes the number of shared libraries loaded at runtime, but requires the -libname parameters to -libname after the object files.