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]

Re: compile failure due to undefined symbol


On Tue, 2 Oct 2007, Daniel Jacobowitz wrote:

> What dynamic tags (readelf -d) does it have before and after?  If your
> patch has no effect on the dynamic tags of installed libraries, then
> it's surely fine; it only affects running things from the build
> directory.  But if it adds an rpath to the installed libraries, I
> think we should avoid that.

 I have just noticed this thread, so no answers to specific bits, but some 
general notes.  Apparently we have some confusion in the tree about how 
libtool works.  I noticed it a few days ago quite spectacularly when 
trying to build cross-binutils.  I do build shared libraries for all 
configurations and in particular for cross-tools I skip archive libraries 
altogether.

 We have this RPATH_ENVVAR setting in the top-level directory.  It breaks 
things.  For my setup (Linux configurations) it adds some build 
directories to LD_LIBRARY_PATH.  It breaks system-installed tools when 
building a cross-toolchain, because the newly-built BFD library, although 
for the same host, has a different target.  But for a libtool-based setup 
there should be no need to use LD_LIBRARY_PATH or anything like this at 
all.  This is because libtool has explicit support for running uninstalled 
newly-built binaries via the "--mode=execute" option.  This option, under 
the bonnet, does all the relinking/rpath/whatever hassle is required for 
the given platform.  All that is required is that .la files are used to 
refer to libraries dependent on during the build and libtool.

 Of course there may be bugs in libtool, in particular in areas hardly 
anybody uses.  But the src/ tree is, I suppose, enough important a user of 
libtool that the maintainers would love to hear feedback from, be it good 
or critical.

 Likewise, all the installed binaries have RPATH set appropriately to 
reach odd locations libraries may be installed in, e.g.:

$ readelf -d /usr/bin/vax-linux-as | grep RPATH
 0x0000000f (RPATH)                      Library rpath: [/usr/i386-linux/vax-linux/lib]

There is no RPATH entry put into libraries themselves as I reckon it is 
not portable; I may be wrong here.  If opcodes depends on bfd, then the 
dependency should be recorded when linking the former -- libtools handles 
it automatically when it sees a .la file on the list of objects being 
linked together.

 Here is a patch I use to make cross-binutils build again, but obviously 
it only covers the problem and the actual fix is outlined above.

  Maciej

binutils-2.18-no-lib_path.patch
diff -up --recursive --new-file binutils-2.18.macro/Makefile.def binutils-2.18/Makefile.def
--- binutils-2.18.macro/Makefile.def	2007-08-06 20:00:27.000000000 +0000
+++ binutils-2.18/Makefile.def	2007-09-29 22:11:31.000000000 +0000
@@ -36,8 +36,8 @@ host_modules= { module= ash; };
 host_modules= { module= autoconf; };
 host_modules= { module= automake; };
 host_modules= { module= bash; };
-host_modules= { module= bfd; lib_path=.libs; bootstrap=true; };
-host_modules= { module= opcodes; lib_path=.libs; bootstrap=true; };
+host_modules= { module= bfd; bootstrap=true; };
+host_modules= { module= opcodes; bootstrap=true; };
 host_modules= { module= binutils; bootstrap=true; };
 host_modules= { module= bison; no_check_cross= true; };
 host_modules= { module= byacc; no_check_cross= true; };


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