Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!decwrl!bothner
From: bothner@decwrl.dec.com (Per Bothner)
Newsgroups: gnu.gcc
Subject: Re: GNU C Cross-compiling
Keywords: gnu c  cross-compilers
Message-ID: <1370@bacchus.dec.com>
Date: 27 Apr 89 19:16:10 GMT
References: <45636@tut.cis.ohio-state.edu>
Distribution: gnu
Organization: DEC Western Research Lab
Lines: 43

In article <45636@tut.cis.ohio-state.edu> hbj@tut.cis.ohio-state.edu (H Benny Jones) writes:
>Is anyone doing any cross-compiler development using GNU C?

Some time ago I ported gcc to the V-system (message-based research
operating system done at Stanford). In the process, I set up
the 68k version of the compiler so that it would run both
"natively" and run under the Vax. I used our old linker, but
used Gnu cpp, cc1, and assembler. Some problems I had:

- The gcc Makefile contains a number of programs for messaging
machine descriptions. These have names of the form gen*.
These run at compiler generation time, as opposed to compile
time. Thus they may need a different compiler than the compiler
itself. (This is not a major problem if all you want is a
cross-compiler, but was a hassle in our world: I wanted two
versions of gcc68, one running on the 68k, one running on a vax.
Normally, a Makefile would define CC=gcc68 to generate a version
running on a 68k. The make could be done either on the 68k or on
the vax, with the operating system running the correct version
of gcc68. But the gen* programs do not fit into this mould:
If you want to re-compile the version of gcc68 that runs on the
68k, but you are re-compiling the compiler on a vax, you risk
re-compiling gen* with gcc68. You then run gen* to make the
compiler itself, and your vax is trying to run a 68k executable!
The solution is to compile gen* in a directory separate from
the compiler proper, using its own Makefile).

- I also had byte-order problems with gdbout.c. I hacked up
some code to byte-swap if needed. It worked, and RMS expressed
interest, but never incorporated it. You should ignore this
problem (by old using dbx-style symbols).

- The output of cc1 was incompatible with our assembler (in minor
annoying ways), so I ported gas. The main problem there was that
our a.out format was different, so I had to hack the output routines.
(Also, gas was somewhat more buggy then...)



-- 
	--Per Bothner
Western Software Lab, Digital Equipment, 100 Hamilton Ave, Palo Alto CA 94301
bothner@wsl.dec.com ...!decwrl!bothner