Re: new library handling in binutils causes trouble with --enable-shared

[Mike Frysinger <vapier at gentoo dot org>]

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.