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-188.8.131.52.17 and
build/install it with --enable-shared, your host binutils will all be linked
$ readelf -d `which as` | grep NEEDED.*2.17
0x0000000000000001 (NEEDED) Shared library:
0x0000000000000001 (NEEDED) Shared library: [libbfd-184.108.40.206.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:
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 ...
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 ?
2.18 is still broken and i dont think cvs head has any changes to indicate this
here's the thread on the mailing list with a bit more info:
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
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
> 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:
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 ?
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
This regression was caused by
which sets LD_LIBRARY_PATH to the newly built libbfd.so and