Bug 4970

Summary: new library handling in binutils causes trouble with --enable-shared
Product: binutils Reporter: Mike Frysinger <vapier>
Component: binutilsAssignee: unassigned
Status: RESOLVED FIXED    
Severity: normal CC: bug-binutils, hjl.tools
Priority: P2    
Version: 2.24   
Target Milestone: ---   
URL: http://sourceware.org/ml/binutils/2012-08/msg00451.html
Host: Target:
Build: Last reconfirmed:

Description Mike Frysinger 2007-08-28 23:39:50 UTC
the new build system in binutils sets up custom LD_LIBRARY_PATHs which can cause
conflicts between the build and host.  if you take binutils-2.17.50.0.17 and
build/install it with --enable-shared, your host binutils will all be linked
against libbfd-2.17.50.0.17.20070615.so:

$ readelf -d `which as` | grep NEEDED.*2.17
 0x0000000000000001 (NEEDED)      Shared library:
[libopcodes-2.17.50.0.17.20070615.so]
 0x0000000000000001 (NEEDED)      Shared library: [libbfd-2.17.50.0.17.20070615.so]

but if you turn and and try to build it again, the LD_LIBRARY_PATH will be set
to your local build directories:
LD_LIBRARY_PATH=.../build/bfd/.libs:.../build/opcodes/.libs:....

and this makes your installed `as` very angry, especially when cross-compiling
as the local libraries are not targetting the same thing as your host libraries.

i cant think of any use for these LD_LIBRARY_PATHs as each binutils utility
includes a little libtool wrapper script which allows you to execute them in the
build dir and make sure the local shared libs are found and used properly ... so
`make check` would work OK ...
Comment 1 Nick Clifton 2007-09-28 09:50:18 UTC
Hi Mike,

  Is this PR still a problem ?  If so, please could you tell me a little bit
more about it ?  (I am not very good when it comes to configure/install issues).
 Is the problem that if you build a set of --enable-shared native binutils,
install them, and then use them to build another set of binutils, this time for
a cross-target, that these cross-binutils will use the wrong shared libbfd ?

  Could you put together a simple test case or set of steps to follow that shows
the problem ?

  Do you have any suggestions as to how the problem might be solved ?

Cheers
  Nick
Comment 2 Mike Frysinger 2007-09-28 19:25:17 UTC
2.18 is still broken and i dont think cvs head has any changes to indicate this
being fixed

here's the thread on the mailing list with a bit more info:
http://sourceware.org/ml/binutils/2007-07/msg00401.html

what you described is the problem (except for the cross-binutils part, it doesnt
matter what the target is, but that too would be a problem)

the way to reproduce is:
 - build/install binutils like normal except add --enable-shared to configure
 - build/install binutils again with --enable-shared, and it'll fail during the
compile stages

my fix for the problem would be to not set LD_LIBRARY_PATH at all ... i dont
know why it's needed, but it certainly isnt so the freshly compiled binaries can
find the freshly compiled libraries -- the fact that we're using libtool means
this is already taken care of
Comment 3 Nick Clifton 2007-10-02 12:16:44 UTC
Subject: Re:  new library handling in binutils causes trouble
 with --enable-shared

Hi Mike,

> the way to reproduce is:
>  - build/install binutils like normal except add --enable-shared to configure
>  - build/install binutils again with --enable-shared, and it'll fail during the
> compile stages

(Just to confirm: between the first step and the second step above I should 
change my PATH so that the newly installed binaries from the first step are now 
ahead of any other binaries and so will be used in the build of the second step).

I tried this, but both builds and installs ran to completion and I was able to 
run the resulting installed binaries without problems.

One possible cause for this was that I was using the current mainline sources 
with the patch from this email applied:

   http://sourceware.org/ml/binutils/2007-10/msg00019.html

Although the patch is for a related problem I am not sure that it is 
responsible for making my builds/installs work whereas yours do not.  Could you 
put together a small shell script that I could use to reproduce the problem ?

> my fix for the problem would be to not set LD_LIBRARY_PATH at all

Do you have a patch that does this, so that I could take a look at it ?

Cheers
   Nick

Comment 4 Mike Frysinger 2007-10-02 17:45:27 UTC
i think that thread is fleshing itself out such that it'll fix the issue i raised

i opened the bug because i couldnt seem to get traction on the mailing list, but
that seems to be changing with the new thread, so i'll just follow up to the
mailing list from now on until it gets resolved ...
Comment 5 H.J. Lu 2012-08-25 22:52:13 UTC
A patch is posted at

http://sourceware.org/ml/binutils/2012-08/msg00451.html
Comment 6 H.J. Lu 2012-08-25 23:03:43 UTC
This regression was caused by

http://sourceware.org/ml/src-cvs/2006-q2/msg00082.html

which sets LD_LIBRARY_PATH to the newly built libbfd.so and
libopcodes.so.