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