This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
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; };