Bug 834104 - Restore prior linker behaviour
Restore prior linker behaviour
Status: CLOSED NOTABUG
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: binutils (Show other bugs)
unspecified
All Linux
unspecified Severity high
: beta1
: 1.1
Assigned To: Jeff Law
qe-baseos-tools
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-20 15:55 EDT by Jeff Law
Modified: 2012-09-13 13:02 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-13 13:02:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Make --add-needed the default. (791 bytes, patch)
2012-07-06 05:14 EDT, Nick Clifton
no flags Details | Diff

  None (edit)
Description Jeff Law 2012-06-20 15:55:00 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:
Comment 2 Nick Clifton 2012-07-06 05:14:25 EDT
Created attachment 596607 [details]
Make --add-needed the default.
Comment 3 Nick Clifton 2012-07-06 05:25:26 EDT
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
Comment 6 Jeff Law 2012-08-17 13:30:50 EDT
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.
Comment 7 Matt Newsome 2012-09-10 11:31:21 EDT
Re-assigning to Jeff to conclude.

Note You need to log in before you can comment on or make changes to this bug.