>>>>> "Curt" == Curt Sampson <curt@portal.ca> writes:

Curt> 1. Cross-compile for the sun3 on my i386 1.0 system.

Curt> Presumably this means building as much of the i386 2.7.2
Curt> compiler as I can under 2.5.4, building the entire i386 2.7.2
Curt> compiler, and then building the sun3 2.7.2 compiler hosted on
Curt> the i386 under the i386 2.7.2 compiler. Of course, I have to
Curt> maintain the 2.5.4 compiler for work on some production 1.0
Curt> systems I have here.

I suspect you mean 2.4.5 :-)

Curt> Does anyone know of any documents that would help me out with
Curt> building a cross-compiler and hosting these three compilers on
Curt> one system? Or have any useful tips?

Building a cross-compiler isn't hard if you drop NetBSD's imported gcc
source.  Use straight FSF source instead.  However you might have
problems to build a cross-assembler, -linker and other utilities (ar,
ranlib, etc).  NetBSD's import has explicitly preconfigured the ports
compilers so building a cross-compiler out of that is... ummm...
"non-trivial".  Actually this is the reason OpenBSD does the gcc import
differently.  When you get the FSF sources, configure it like this:

configure --host=i386-unknown-netbsd --target=m68k-unknown-netbsd

No need to spec the manufacturer unless it's a HP, as all m68k archs
running NetBSD except HP is compatible.  After this just "make"!

Wrt to the assembler, linker and other utils, you still need the
NetBSD variants as the PIC support isn't in at Cygnus (ie FSF).  I
hope you get some answers from someone who has already done the work
for you, otherwise you'll have some hacking to do.  It's mainly
endianness problems as the target and host are both NetBSD, so object
formats is no problem per se.  I guess magic numbers need attention
too.  I'm slowly working on getting the FSF versions useable but it
won't happen in the foreseeable future.  If you get into a dead-end on
this, come back to me and we'll see what you need, exactly.  Perhaps
some of our priorities coincide.

Curt> 2. Keep multiple object trees on one system.

Curt> I'd like also to be able to produce a full current/i386 compile
Curt> and current/sun3 compile from the same source tree. The files in
Curt> /usr/share/mk seem to have some facilities to help with this,
Curt> but they don't seem obvious at first glance. Are these
Curt> documented anywhere other than the README in that directory?

Don't know if they are, but they aren't to hard to use anyway.  Just
define OBJMACHINE in your env.  If you want obj.${MACHINE} to be
symlinks to different physical trees as well, you should define
USR_OBJMACHINE as well.  I'd say: do both.  Then you'll get entries
like obj.sun3 that are links to /usr/obj.sun3/foo/bar or wherever you
have your objtree (BSDOBJDIR).

Curt> 3. Keep multiple source and object trees in one system.

Curt> It would be nice, at some point, to have all of the three
Curt> different versions I use under source code control, with
Curt> branches for my modifications to each version, and the like, and
Curt> the ability to pull out and compile, using the appropriate
Curt> compiler for that version and target host, whichever version I
Curt> need. However, this is more of a dream item than something I may
Curt> be working on in the near future. I would be interested in
Curt> comments from anyone doing this sort of thing already.

Well It should not be too hard technically.  But you're right, you
need a bit of time to set it up.

Niklas

Niklas Hallqvist       Phone: +46-(0)31-40 75 00  Home: +46-(0)31-41 93 95
Applitron Datasystem   Fax:   +46-(0)31-83 39 50  Home: +46-(0)31-41 93 96
Molndalsvagen 95       Email: niklas@appli.se     GSM:  +46-(0)70-714 10 35
S-412 63  GOTEBORG     WWW:   Here
Sweden		       IRC:   niklas (#NetBSD)