bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Trouble building cross-assembler for m68hc11


From: Bernd Jendrissek
Subject: Trouble building cross-assembler for m68hc11
Date: Fri, 7 Mar 2003 12:33:48 +0200

[Please Cc: me if you're not a "post here, read here" fundamentalist.]

I've tried to build a cross-assembler for m68hc11 but it bombs:

gas/.libs/as-new: error while loading shared libraries: 
/usr/lib/libopcodes-2.13.90.0.18.so: undefined symbol: 
floatformat_ieee_double_big

Here's how I build the thing:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var 
--infodir=/usr/share/info --mandir=/usr/share/man --target=m68hc11 
--enable-shared --enable-64-bit-bfd
make all-gas
...
make install-gas

When I delete gas/.libs/as-new and gas/as-new and re-run 'make all-gas', the
(only) rule to rebuild that's executed is this:

/bin/sh ./libtool --mode=link gcc -W -Wall -Wstrict-prototypes 
-Wmissing-prototypes -g -O2  -o as-new  app.o as.o atof-generic.o bignum-copy.o 
cond.o depend.o dwarf2dbg.o ecoff.o ehopt.o expr.o flonum-copy.o flonum-konst.o 
flonum-mult.o frags.o hash.o input-file.o input-scrub.o listing.o literal.o 
macro.o messages.o output-file.o read.o sb.o stabs.o subsegs.o symbols.o 
write.o tc-m68hc11.o obj-elf.o atof-ieee.o  ../opcodes/libopcodes.la 
../bfd/libbfd.la ../libiberty/libiberty.a   
gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -o .libs/as-new 
app.o as.o atof-generic.o bignum-copy.o cond.o depend.o dwarf2dbg.o ecoff.o 
ehopt.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o frags.o hash.o 
input-file.o input-scrub.o listing.o literal.o macro.o messages.o output-file.o 
read.o sb.o stabs.o subsegs.o symbols.o write.o tc-m68hc11.o obj-elf.o 
atof-ieee.o  ../opcodes/.libs/libopcodes.so ../bfd/.libs/libbfd.so 
-L/usr/src/home/rpmtest/tmp/BUILD/binutils-2.13.90.0.18/libiberty/pic -liberty 
../libiberty/libiberty.a -Wl,--rpath -Wl,/usr/i686-pc-linux-gnu/m68hc11/lib

That breaks.  Notice that libbfd and libopcodes are linked in from the
binutils build tree, not from /usr/lib.

My installed binutils live in --prefix=/usr, and are configured with
--enable-targets=all, so libopcodes and libbfd contain (I thought) code for
*everything*.

Here's something that works:

gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -o .libs/as-new 
app.o as.o atof-generic.o bignum-copy.o cond.o depend.o dwarf2dbg.o ecoff.o 
ehopt.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o frags.o hash.o 
input-file.o input-scrub.o listing.o literal.o macro.o messages.o output-file.o 
read.o sb.o stabs.o subsegs.o symbols.o write.o tc-m68hc11.o obj-elf.o 
atof-ieee.o -lopcodes -lbfd 
-L/usr/src/home/rpmtest/tmp/BUILD/binutils-2.13.90.0.18/libiberty/pic -liberty 
../libiberty/libiberty.a -Wl,--rpath -Wl,/usr/i686-pc-linux-gnu/m68hc11/lib

The only change is that I've linked with libbfd and libopcodes in /usr/lib
instead of those in the build tree.

It seems that libopcodes in the build tree *doesn't* need
floatformat_ieee_double_big, whereas the one in /usr/lib *does*.  Therefore
the failure at runtime.  So then why is floatformat_ieee_double_big
seemingly elided from the executable (where it is linked in statically from
libiberty)?  A linker optimisation, I guess...

So, other than patching the Makefile, what is the easiest way for me to
get a working cross-assembler that works with the installed libopcodes and
libbfd?  Should I ./configure binutils with --enable-targets=all (yuck)
just to build the cross-assembler?  (Trying that now, I'll know in a couple
of hours.)  Ideally this solution would work too for building other
cross-assemblers...

bernd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]