This is the mail archive of the 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]

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

On 7/25/07, Mike Frysinger <> 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- and build/install it with --enable-shared, your host
binutils will all be linked against

$ readelf -d `which as` | grep NEEDED.*2.17
 0x0000000000000001 (NEEDED)             Shared library:
 0x0000000000000001 (NEEDED)             Shared library:
 0x0000000000000001 (NEEDED)             Shared library: []

but if you turn and and try to build it again, the LD_LIBRARY_PATH will be set
to your local build directories:

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).

Your use of passive voice ("will be set") confuses me... where is
LD_LIBRARY_PATH getting set other than in the libtool wrapper scripts?

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

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?

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]