hbj@tut.cis.ohio-state.edu (H Benny Jones) (04/28/89)
Is anyone doing any cross-compiler development using GNU C? For example, I'd like to have a 386 cross-compiler hosted on our VAX (VMS) system.
bothner@decwrl.dec.com (Per Bothner) (04/28/89)
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