Xref: utzoo comp.sys.sequent:34 comp.sys.m68k:937 comp.sys.intel:471
Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!ncar!noao!nud!fishpond!fnf
From: fnf@fishpond.UUCP (Fred Fish)
Newsgroups: comp.sys.sequent,comp.sys.m68k,comp.sys.intel
Subject: Re: cross-compiling with byte-swapped machines
Message-ID: <114@fishpond.UUCP>
Date: 10 Jul 88 00:58:08 GMT
References: <4352@pasteur.Berkeley.Edu>
Reply-To: fnf@fishpond.UUCP (Fred Fish)
Distribution: na
Organization: occasionally
Lines: 27

In article <4352@pasteur.Berkeley.Edu> aoki@postgres (Paul M. Aoki) writes:
>GNU cc seems to work fine on the Symmetry, so I can produce 68020
>assembly code.  All I need is a working 68K /bin/{as,ld} and I'm set.
>Problem: programs that produce .o files are just a *little* more
>sensitive to byte-ordering than compilers, and the 68K and 386 have
>reverse byte-ordering.  I really don't want to go through every line
>of Sun's as and ld (or the GNU as and ld) and stick byte-swapping
>macros in -- someone somewhere must have done something like this before!

As someone who has supported m68k cross compilation environments for 
several years on a number of different systems, including some with
different byte ordering than the m68k, I would advise making only
minimal changes in the source code of the tools themselves.  Use
the natural byte ordering of the host machine, and convert the
object files with a conversion program when you need to actually
transfer and execute them on an m68k based machine.  Writing the
conversion program will almost certainly be less work than weeding
out all the byte dependencies in the tools.  Conversion tools for
COFF objects and "a.out" objects are available from many vendors
that support m88k cross environments, though this might not be
useful to you if you are trying to work totally with freely
redistributable software.

-Fred
-- 
# Fred Fish, 1346 West 10th Place, Tempe, AZ 85281,  USA
# noao!nud!fishpond!fnf                   (602) 921-1113