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] |
>-----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] |