Re: Re Crosscompiling a native compiler

[Kai Ruottu <karuottu at freenet dot hut dot fi>]

Frank Meurer wrote:
> 
> > > > ./configure --with-gnu-ld --with-gnu-as --host=m68k-unknown-linux
> > > m68k-unknown-linux
>
> I thought that one should not specify build because the configure-script
> tries to do it.

 Don't think the configure-maker is a super-human... Everybody can make
mistakes, but your words sound like you are thinking that there cannot be
any bugs in the configure script...

 So I use the '--build=<my_machine>' (now 'i586-linux-gnulibc1') always,
never letting it to guess anything.
 
> Your "host code" can be run on your "build machine" (I guess!) and
> therefrom you won't have *my* problem, that the compiled "xgcc"-file
> (m68k-code) can't be executed on my i386-build-machine.

 When it tries to do stupid things like this, you should think "I'm the
'homo sapiens' - the wise human, but the stupid machine cannot do anything
right at the first trial...".  So, change the 'what-to-do' instructions for
it... Just track the commands from the Makefile and see what it now does
wrong... (the original writer gave it wrong orders)

 Please browse the messages in this list a week or so backwards and see
what I wrote about fixing those '<toolname>_FOR_TARGET', '..._FOR_BUILD',
HOST_CC, OLDCC etc. Anything in them just can be wrong...

> After spending much hours I say it's IMHO impossible to build a native
> gcc-2.7.2.3 for a foreign hardware in ONE stage because the compiled
> "xgcc" (will later be renamed) will be invoked but cannot be executed.

 It is just a bug, please fix the bug and continue...
 
> There are significant changes between gcc-2.7.x and gcc-2.9x!

 Yes, the 2.7.x configure script and the resulted Makefile had many, many
more bugs... (The gcc-2.95.2 configure has still bugs, but not so many).
There will be no new gcc-2.7.x releases, so trying to fix or report the bugs
in configure is vain. Just edit the resulted Makefile.

 I have built a native compiler (DOS/DJGPP, Cygwin, Mingw, emx, mips-sysv4,
etc.) at least ten times under Linux. There may have been problems, but never
very hard... Just those like HOST_CC pointing to the 'host' compiler (whatever
the name hints, it should be the 'build' compiler), OLDCC being always 'cc' (it
should be the same as GCC_FOR_TARGET), GCC_FOR_TARGET set to be './xgcc -B./'
(should be the installed cross compiler for the 'host/target', 'm68k-linux-gnu-gcc'
in this case) and so on... This last bug, if there, could be the reason why
it tries to run './xgcc -B./' as the compiler to produce the target binaries...

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