Re: build powerpc cross compiler

[Kai Ruottu <kai dot ruottu at luukku dot com>]

Edward Krichmar wrote:

> I am attempting to make a cross-compiler for powerpc-linux on Host x86.
> First step - build tree by script  "one-tree-1.6.sh " is succeded without
> any problem. But after this - by executing `build-cross.sh'  I a see follow
> problem:
>
>         ------------------- start dump ----------------
> gcc -W -Wall -g -O2 -o objdump objdump.o prdbg.o rddbg.o debug.o stabs.o
> ieee.o rdcoff.o bucomm.o version.o filemode.o ../opcodes/.libs/libopcodes.a
> ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -ldl
> objdump.o: In function `objdump_print_symname':
> /home/edi/tools_ppc/b-powerpc-linux/binutils/../../src/binutils/objdump.c:70
> 9: undefined reference to `demangle_symbol'
> objdump.o: In function `dump_symbols':
> /home/edi/tools_ppc/b-powerpc-linux/binutils/../../src/binutils/objdump.c:23
> 87: undefined reference to `demangle_symbol'
> objdump.o: In function `main':
> /home/edi/tools_ppc/b-powerpc-linux/binutils/../../src/binutils/objdump.c:29
> 68: undefined reference to `init_demangler'
> collect2: ld returned 1 exit status
>         ------------------- end dump dump ----------------
>
> Is there some way to solve the problem?

 Let's first assume your 'binutils' release being untouched and in original
condition...

 Please use your 'grep' and 'nm' to search the `demangle_symbol' and
`init_demangler' in the sources and the produced libraries in the opcodes,
bfd and libiberty subdirs... I would suspect these being or to be in libiberty
in the 'cplus-dem.c' and in the resulted 'cplus-dem.o' in 'libiberty.a'...

 I cannot imagine what on earth could have happened, but doing a 'make clean'
in the guilty subdir and then rebuilding again with redirecting the output
messages into a logfile, and then looking at the logfile something must come
out... Ok, please use something like:

  make > MakeLog 2>&1

when building again...

 But perhaps some evil has come and spoiled your binutils sources...

 Please forget all the weird scripts from the CrossGCC FAQ, doing things
one at a time is much more clear... If a script is used the script-maker should
have warned that it may break something if not used with just the mentioned
components...

 What on earth is this "one-tree-1.6.sh" when after building hundreds of
cross-tools I have never needed it?

> I use Slackware 7.1 Linux version with kernel 2.2.16

 For instance the output you gave didn't reveal even as important a thing like
the version for the binutils you used. When you build binutils, you will meet
the same problems other binutils builders may have met... And the problems are
always known related to a specific binutils version. Telling your Linux version
and the kernel version has absolutely nothing to do with this problem...

 It is well-known that the current GCCs, binutils and GDBs all come with the
'libiberty' subdir, and binutils and GDB have the common 'bfd' and 'opcodes'
subdirs. But if you think that it doesn't matter what you take and where and
then make a single source-tree-mixing, you are badly wrong...

 Of course replacing the whole 'libiberty', 'bfd' or 'opcodes' subdir from some
newer release into some older sources is possible, but then you must know what
you are doing and be able to fix things to make the 'updated' sources to work
again...

 I would assume the "one-tree-1.6.sh" doing some kind of source-mixing and that
being the biggest problem now...

 If you want a somehow tested 'all-in-one' source-tree, taking the RedHat EDK-
sources for embedded-x86/PowerPC/Linux targets from March-2000 or the newer
XScale-gcc-3.0-beta sources and trying them is one solution... Or use the
Montavista HardHat sources... Or use separate binutils, GCC, glibc and GDB
sources and build one at a time, or make your combined source-tree in the same
way RedHat and MontaVista (perhaps) have done, if you feel capable to that...
But please don't trust any weird scripts to do this for you. This is crude but
it is the plain truth...
 
 If you have a RedHat 6.x, taking the RedHat-EDK or the HardHat binaries as
the base, you will have a little old toolset, but it should work immediately.

 Updating the toolset components one at a time later is always possible...

   ftp://ftp.redhat.com/pub/edk    (or the mirrors)
   ftp://ftp.redhat.com/pub/gnupro (the xscale-distribution)
or
   http://www.montavista.com       (their HardHat-distributions)

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com