This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: SPARC Cross Compiler


>-----Original Message-----
>From: David Dudley [mailto:david.dudley@starblade.com]
>Sent: 16 October 2001 04:24
>To: crossgcc@sources.redhat.com
>Subject: SPARC Cross Compiler
>
>
>Hey guys!
>
>I need to build a sparc-rtems-elf cross compiler, hosted on a 
>i586-pc-linux-elf host.
>
>I configured the compiler with <configure --host=i586-pc-linux-elf 
>--target=sparc-rtems-elf --with-newlib>
>
>When I build the compiler with 'make cross', things go fine, 
>till the end of 
>stage1.  As soon as it tries to do 'stage2', the configure 
>fails, with the 
>fact that 'xcc can't build executables'.  What's it trying to 
>do, generating 
>the stage2 compiler trying to use the target compiler, instead 
>of the host?


  This is a gcc-2.95.x backwardly compatible answer to your question.
It may or may not still apply to 3.0.x, check the build instructions in the
manpage/info file for further details, but one thing is that when you
build a cross-compiler you don't make stage2, or any of the others.  In
fact, you shouldn't even use 'make cross', the only two targets you
should make are 'all' and 'install'.

  This is because the entire point of stage2 is to rebuild the newly
built compiler *using the newly built compiler to do so*.  You can see
why this will not work for a cross compiler.  The point is that you may
be building a native compiler using the manufacturer's own-brand compiler
that comes with your system; since many of the system compilers for the
original unix targets for gcc were known to have bugs, quirks or oddities
with their codegen, the 2nd stage builds a version of gcc that has been
built using gcc instead of the manufacturer's compiler, thereby hopefully
guaranteeing that any quirks have been ironed out.  The stage3 then uses
this hopefully-sound gcc to build itself once more, and compares the
object files resulting; they should be the same.

  None of which makes sense or is possible for a cross-compiler, and the
only thing to do in that case is to use gcc instead of any mfr's native
compiler in the first place.


       DaveK
-- 
Burn your ID card!  http://www.optional-identity.org.uk/
Help support the campaign, copy this into your .sig!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]