Re: powerpc crosscompiler error

[Geir Frode Raanes <geirfrs at invalid dot ed dot ntnu dot no>]

On Tue, 7 Dec 1999, Peter Popov wrote:

> I'm running into the following problem when trying to
> build a linux-hosted powerpc-eabi cross-compiler:

(More specifically, building the IEEE754 double precision floating
 point library libgcc2.a that apparently is implemented through
 multiple calls to the IEEE754 single precision library libgcc1.a.
 The libgcc1.a library is OTOH implementet as CPU specific assembly
 listing, or - if this assembly listing is not available - a set
 of macrodefinitions that one assumes the compiler compiling gcc
 knows how to expand into legal floating point code. This, needless
 to say, does not work when building gcc cross compilers.
 Both libraries, libgcc1.a and libgcc2.a are later on merged into
 the final libgcc.a library. I hope someone that actually knows
 can confirme or reject my findings here.)

> ---snip--------
> make 	GCC_FOR_TARGET=	"/local/ppopov/gnu/b-powerpc-eabi/gcc/xgcc 

The temporay 'xgcc' powerpc compiler control program does not know
where to find its powerpc binutils, neither what program-prefixes
are prepended to their naked names. It simply search the below
listed '-B<dir>' directories for 'as' and if needed 'ld.' 
If not found in any of those, 'xgcc' resorts to search $PATH.

>			-B/local/ppopov/gnu/b-powerpc-eabi/gcc/ 
>			-B/usr/powerpc-eabi/bin/ { == $(prefix) }
>                       -I/usr/powerpc-eabi/include" \

Now, the last '-B<dir>' directory is where "powerpc-eabi-as"
is located. Unfortunately, as above stated, the 'xgcc' control
program will not use the full "powerpc-eabi-as" name but rather
the naked "as" name.

Thus, due to this oversight in the <configure.in> template you will
have to add </usr/powerpc-eabi/$(tooldir)/bin> first in $PATH.
This is where binutils placed the naked executeables for powerpc.
You will find the $(tooldir) varibale in the toplevel Makefile of
binutils. Needless to say, the binutils and gcc Makefile value of
this variable must agree, as must the $(prefix) variable. 
As a sidenote, the native 'gcc' control program _do_ know where 
to find it's native binutils [builtin + specs file] and will as 
such not be confused by cross developement binutils in PATH.

>   	LANGUAGES="c c++" 

If you use the <gcc-2.95.2-__core__-...> distribution, patch all
the above occurences to read LANGUAGES="c" in the toplevel Makefile
</local/ppopov/gnu/b-powerpc-eabi/Makefile>

> for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 
>	_negdi2 _lshrdi3 _ashldi3 _ashrdi3 _ffsdi2 _udiv_w_sdiv
>	_udivmoddi4 _cmpdi2 _ucmpdi2 _floatdidf _floatdisf
>	_fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi _fixunssfdi
>	_fixsfdi _fixxfdi _fixunsxfdi _floatdixf _fixunsxfsi
>	_fixtfdi _fixunstfdi _floatditf __gcc_bcmp _varargs __dummy
>	_eprintf _bb _shtab _clear_cache _trampoline __main _exit
>	_ctors _pure; \  /* MEMBER FUNCTIONS OF <libgcc2.a>*/
> do echo ${name}; \
>   /local/ppopov/gnu/b-powerpc-eabi/gcc/xgcc
>			-B/local/ppopov/gnu/b-powerpc-eabi/gcc/ 
>			-B/usr/powerpc-eabi/bin/
>			-I/usr/powerpc-eabi/include 
>			-O2  -DCROSS_COMPILE -DIN_GCC -DHAIFA    
>			-g -O2 -I./include   -g1  -DIN_LIBGCC2 
>			-D__GCC_FLOAT_NOT_NEEDED 
>			-Dinhibit_libc -mstrict-align 
>			-I. -I../../src/gcc -I../../src/gcc/config 
>			-I../../src/gcc/../include -c 
>			-DL${name} ../../src/gcc/libgcc2.c 
>			-o ${name}.o; \
>   if [ $? -eq 0 ] ; then true; else exit 1; fi; \
>
>  	 powerpc-eabi-ar rc tmplibgcc2.a ${name}.o; \

/* AR_FOR_TARGET */

>   rm -f ${name}.o; \
> done
> _muldi3
>
> as: unrecognized option `-ppc'

No, the native x86 'as' in $PATH does not know any '-ppc' option.

Now, modifying $PATH (or softlinking in the above -B<dir>' or
adding the correct -B<dir> to the Makefile) and making sure
"$prefix, $tooldir" and "$program_transform_name" agrees
between binutils and gcc will get you past <libgcc.a> 

But your build will still crash on libiberty. For reasons I do not
understand, "make all" will try to build libiberty twice. First
native as it is supposed to, then later on crosscompiling the same
files. Which, for libiberty, makes no sence. I have yet to figure
this one out. Please help me/us out here.

Personally, I am trying to build '--target=powerpc-wrs-vxworks' 
for gcc and '--target=powerpc-wrs-elf32' for binutils, changing
"$program_transform_name" and "$tooldir" for binutils to agree
with the corresponding variables in gcc.


--
  ******************************************************
  Never ever underestimate the power of human stupidity.
  -Robert Anson Heinlein

		GeirFRS@invalid.and.so.forth
  ******************************************************



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