> 
> Hello,
> 
> FYI,
> 
> > Work to do: linking dynamically, tweak the NetBSD tree to allow it be
> > compiled by a cross-compiler, test other NetBSD ports as targets.
> > Volunteers?   
> 
> When you get to the kernel, the only thing that should be needed
> (this applies more generally) is to clean up
> 
> 	sys/arch/<targ>/config/Makefile.<targ>
> 
> some things to check:
> 
> 	o	change strip to ${STRIP} (with a default
> 		of strip).
> 
...
> 	o	Addition of -nostdinc to kernel includes path
> 
> 	o	Check that lorder uses ${NM} (It should
> 		by now)

Under NetBSD 1.0 I had created a successful NetBSD/i386 -> NetBSD/m68k
cross compilation environment for a port to a 68k processor board I worked
on earlier this year.

This was back in january, so this is off of the top of my head.

I had rewritten strip, nm, and size (possibly others) to work
based off of the magic header in the file so they would correctly 
work for any known endian executable/object.

I also had problems with as and ld that I resolved with code fixes.
Some of the fixes that I had to make were made and checked in by someone
else in parallel.

If anyone is intrested in my cross environment or how it was set up.
I could get the files off an old disk and send them.

I didn't maintain the changes or check them against -current because
once I had a native compilation environment I just used it.

One last problem that I never fully fixed was a problem with the kernel build.

When genassym is compiled (for the host machine) it may not have the
same data alignment as the target machine, this can mess up certain constants.

I found a workaround but never really used it because I got my native
environment working at that time. The workaround had to due with
putting a "#pragma pack (n)" in some header. I do not recall what the "n"
value was.

I believe that X86 aligns 32 bit values to 32bit alignment and 68k only
uses 16 bit alignment for 32bit values. (???)

Dale Rahn					drahn@urbana.mcd.mot.com
Not representing my employer