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 ...
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
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
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
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 ...
A patch is posted at http://sourceware.org/ml/binutils/2012-08/msg00451.html
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.
Fixed by http://sourceware.org/git/?p=binutils.git;a=commitdiff;h=31fbd2751dfe5c835161763cda18e5ab74d43141