| Summary: | new library handling in binutils causes trouble with --enable-shared | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Mike Frysinger <vapier> |
| Component: | binutils | Assignee: | 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
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. |