Re: Problem building cross-gcc for powerpc-linux

[Duane Ellis <duane_ellis at franklin dot com>]

>> I appreciate your understanding, Kai, really.  But I run PPC, ARM,
   MIPS, 68K, and SH cross compilers (yes all of them, I'm not being
   hypothetical) on my X86 workstation.  Where the f%!k am I going to
   get a GNU-powered ARM, MIPS, 68K or SH workstation to copy header
   files from?

I too have this problem. I current run the following ports of GCC

  target: 6502 - (based on 2.95.3 - not a complete C compiler it has 
		 one major limitations, no variable can live on the stack
		 you must always use optimization, we did this
		 internally)
  target: ByteCodeInterpretor (Another internal custom port we did)
	          Not publically released.
  target: Sneak24 (Our custom 24bit cpu, another one we did internally)
		  Not publically released.
  target: Sneak32 (Our custom 32bit cpu - see http://www.franklin.com/ebookman)
		  the sneak32 tool chain is in the ebookman SDK.
  target: ARM

host platforms vary - but include: SunOS 4.1, Solaris, Linux and Cygwin.

What GCC is missing is a "./configure --bootstrap" option that tells
GCC that you are trying to "boot strap" the compiler and that
*NOTHING* else is in place yet.

The way GCC is setup it is a horrible a catch22.

There are situations where - you are porting to a new system and you
do not have any header files what so ever to work from, and hence
libgcc cannot even be built.

What if you are the guy writing the compiler port? Eh?

There should be a way to "bootstrap" GCC when you don't have an
assembler, and you compile everything with the "-S" option, and run
the assembler as a seperate step in your makfiles. Problem is - GCC
only knows how to execute UNIX style assemblers.

We have written shell script wrappers that convert arguments on the
fly. It works - but it is a pain (See the sneak32 tool kit for)

Not every target can build libgcc - The methods that the GCC sources
uses may not be able to a library. I have this problem.

To compile and run GCC for the purposes of boot strapping - you only
need only about 4 files installed. (ie: Look at the "xgcc" target that
the GCC build process makes use of) 

It sure would be nice to tell the system "stop right there and install
this" GCC is missing that exact option.

Another problem is GCC cannot be built if you cannot create a library
Darn thing demands to build 'libgcc' as a library. The Build process
for GCC seems to think - You must be able to create a library....
Sometimes you cannot. It might have to be done a different way that
cannot be described to GCC easily.

It would be nice to have a "./configure --no-libgcc" which tells GCC
that it should NOT try to build the LIBGCC and just assume that it is
not needed, or that it will be there some time later.

There are other problems - some times when you build external packages
it says "installation problem GCC cannot build executables".  Well DUH
sometimes it cannot. It is perfectly valid for GCC *NOT* to be able to
do the final step of producing an executable.

Example: You need to create a ROM - which includes reset vectors,
interrupt handlers, and all that sort of stuff, and there is no Unix
style linker available.

The compiler should, and can work in this environment. I know it can
because that is how we have to do it and it works and has been working
for years.

----

I would have no objection to having GCC boot strap in several phases.
For example:

Phase 1 - Build and Install the only C compiler, using some
          "--bootstrap" option.

Phase 2 - Out side of the GCC build directories, use some other tools
          and the 'partial-install' of GCC to build some more stuff
	  
Phase 3 - Blow away the source & configured compiler and
          reconfigure - this time - you can boot strap further.

Repeat this several times, adding features each step.

It is a REAL PITA but that is the way I have to do it right now.

-Duane.


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