This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wednesday 25 July 2007, Bernd Jendrissek wrote: > On 7/25/07, Mike Frysinger <vapier@gentoo.org> wrote: > > 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] > > 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] > > > > 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:.... > > That looks like libtool magic where build/binutils/objdump is really a > shell script that sets up LD_LIBRARY_PATH and then runs > build/binutils/.libs/objdump (the uninstalled binary). normally, yes, this logic would be confined to the libtool wrapper script which would setup the env and then execute the real binary in .libs/ ... but i'm not looking at the binaries as the infected build env prevents them from even being generated yet. > Your use of passive voice ("will be set") confuses me... where is > LD_LIBRARY_PATH getting set other than in the libtool wrapper scripts? read the top level Makefile and you will see that LD_LIBRARY_PATH is exported at the make level (plonk!). > > 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. > > How does your installed 'as' even see the LD_LIBRARY_PATH pointing > into your build directory? > > Also, doesn't a cross-as use RPATH so that it dynamically links to > exactly the target-specific libraries? LD_LIBRARY_PATH trumps DT_RPATH > > about the only use i can think of for these LD_LIBRARY_PATHs is when you > > go to run `make check`, so perhaps the setting of this variable should be > > restricted to that case ? > > I find it convenient while I'm (re)doing my OMF port to be able to run > objdump from the build directory without having to install it. YMMV. i'm not looking at changing any of the wrapper scripts ... also, this is only an issue with --enable-shared which is not the default -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |