Re: "powerpc-elf-ar : not found" and "libgcc2.a" problem (target 'mak e all' or 'make all-gcc')

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

"Bertin, Philippe" wrote:
> 
> Hello,
> 
> Yes, indeed, thanks, NGC. This helps it somewhat further. Keeps on being
> stuck somewhat further now, though : now doesn't find stdio.h in libiberty
> subdir  :(

 The gcc-2.95.2 sources had this problem, the search paths go via the

   $prefix/lib/gcc-lib/$target/2.95.2/../../../../

into the target headers and libs stuff in

   $prefix/$target

and when this install directory doesn't yet exist, the search fails.
Just check this fact with the './cpp -v' in the 'gcc' build directory.
So the workaround is simple, just create the missing directory...
BTW, don't forget to 'toy' with options like '--help' and '-print-search-dirs'
with the produced new gcc-driver, the 'xgcc'... The '--help' should
be the first option one should learn and a mantra to mumble, otherwise
forgetting to use it in need may be forgotten ;-)  It should work with
all the GNU tools...

 The gcc-2.95.3 sources have this bug fixed, the build creates the
needed install directory, or at least my gcc-2.95.3 sources do this.
Anyway I must be surprised about the gcc-2.95.2 use, because the
'powerpc-elf'-related targets like 'powerpc-eabi*', 'powerpc-linux'
etc. were those who had many bugfixes in gcc-2.95.3. And this is
the current 'stable and rock-solid' release, while the gcc-3.0.2 may
still crash if tried to build for 'powerpc-eabi*' or 'powerpc-elf'.
 
> What's exactly is libiberty doing ? Is it a necessary part of
> the cross-compiler ?

 Libiberty completes the standard C library, 'libc.a', by providing
some GNU-related functions maybe missing from it.  I wouldn't say it
being 'necessary' for the target tools, while building GCC needs it
for the host (the GCC executables use some functions from 'libiberty').

> > > ./configure --target=powerpc-elf

 Of course everyone is expected to know what one is doing, but I
would like to mention that the 'powerpc-eabi' ('Embedded ABI') is
more common for embedded aims, while the 'powerpc-elf' seems to
be for a 'more PowerPC/SVR4-like' toolkit...

	powerpc-*-sysv* | powerpc-*-elf*)
		tm_file=rs6000/sysv4.h
		xm_file="xm-siglist.h rs6000/xm-sysv4.h"
		xm_defines="USG POSIX"
		extra_headers=ppc-asm.h
		if test x$gas = xyes
		then
			tmake_file="rs6000/t-ppcos rs6000/t-ppccomm"
		else
			tmake_file="rs6000/t-ppc rs6000/t-ppccomm"
		fi
		xmake_file=rs6000/x-sysv4
		;;

 Here the 'powerpc-elf' differs from those 'arm-elf', 'm68k-elf',
'mips64-elf', 'fr30-elf' etc. targets, when it is an alias for the
PowerPC/SYSV4-target... Putting it as an 'alias' for 'powerpc-eabi'
would sound to be more better, like :

	powerpc-*-eabi* | powerpc-*-elf*)
		tm_file=rs6000/eabi.h
		if test x$gas = xyes
		then
			tmake_file="rs6000/t-ppcgas rs6000/t-ppccomm"
		else
			tmake_file="rs6000/t-ppc rs6000/t-ppccomm"
		fi
		extra_headers=ppc-asm.h
		;;

 Or is it impossible for anyone to misunderstand the 'powerpc-elf'
to mean the "embedded ELF target for PowerPC", which it seemingly
doesn't mean ?

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