Red Hat Bugzilla – Bug 834104
Restore prior linker behaviour
Last modified: 2012-09-13 13:02:10 EDT
Description of problem: GNU ld in the developer toolset has different symbol resolution behaviour compared to the linker available in RHEL 5 and RHEL 6. Specifically the DTS version of the GNU linker does not search indirect shared libraries to resolve unresolved symbols referenced by the main program. That behaviour was introduced in binutils-2.20 to have GNU ld's behaviour mirror the behaviour of gold. This is a request to restore the old behaviour of the linker as it places a significant burden on customers that utilize large number of shared libraries which are not under their direct control. Version-Release number of selected component (if applicable): How reproducible: The canonical testcase from 2009: foo1.c: #include <stdio.h> extern int foo (); int main () { printf ("%d\n", foo ()); } foo2.c: extern int foo (); int bar () { return foo (); } foo3.c: int foo () { return 0; } gcc -g -fPIC -c foo1.c foo2.c foo3.c gcc -shared -o foo3.so foo3.o gcc -shared -o foo2.so foo2.o foo3.so gcc -o foo1 foo1.o foo2.so -Wl,--rpath-link=. The last line will fail with an undefined reference to 'foo'. The requested change would cause the link to succeed. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 596607 [details] Make --add-needed the default.
Hi Jeff, This change was deliberate. It is intended to force developers to correctly account for all the dependencies associated with their particular application. Thus if they rely upon a third party DSO, they really ought to include it in their dependencies and their linker command line. There is a workaround for the problem. Developers can add "-Wl,--add-needed" to their final gcc link command line. This must be done *before* any object files or libraries are specified. I suspect however that you still want a fix. I have uploaded a patch which is one half of a solution to the problem. This makes the linker default to following DT_NEEDED entries, but it is not sufficient to resolve the issue. The second part of the problem is that RHEL's gcc automatically adds --no-add-needed to the linker command line. This is patch gcc47-no-add-needed.patch in the gcc rpm. That patch will have to be disabled as well, before the problem can be fully resolved. I have not added the binutils-rh834104.patch to the RHEL binutils spec yet as I would like confirmation that you really need this change to go in. Are you surethat it is needed ? If so then I will update the rpm and check in the patch. Cheers Nick
As Nick noted, this was a deliberate change to force developers to correctly account for dependencies in their code and further isolate them from unexpected problems with library updates. This also makes the long term possibility of transitioning to gold easier. I've exchanged some email with Evelyn @ Mentor explaining the situation in more detail and she has agreed that it's not as bad as she first thought. I think this is ultimately going to be CLOSED/WONTFIX or CLOSED/NOTABUG.
Re-assigning to Jeff to conclude.