Subject: cross-building NetBSD (from Linux)
To: None <port-mac68k@netbsd.org>
From: J. MacPhail <jrm@kw.igs.net>
List: port-mac68k
Date: 03/09/2004 23:04:35
Finally I've made it through setting up to cross-build from Linux
(debian-ppc, on a 267 MHz machine).  I didn't find it trivially easy,
but if you are willing to defer attacking current and to start with
1.6.2 (so the following notes directly apply), and you have a
reasonably current Linux on any architecture with adequate disk space,
I think you have a good chance of getting all the cross tools built in
an evening.

The maximum amount of hard drive space used was about 650 MB (more
than the docs would imply), but it can very easily be reduced to less
than 100 MB after the cross-tools have been built.  You can surely get
by with less disk space; I didn't try.  The disk space can very easily
be reduced to less than 100 MB after the cross tools have been built,
and you could perhaps stay within 100MB all along if you get the
source sets gunzipped onto a CD (copying to hard drive a subtree or
two that needs to be writable, and making sym links to the rest).

Building all the cross tools takes about 40 minutes, then a first
build of the GENERIC mac68k kernel takes less than 15 minutes.

Be prepared to do a little tweaking, depending on how different your
system is from what you are building.  In my case, starting with
gcc-3.3 and various other things, I had to additionally install

  1. zlib1g-dev         -- easily figured out
  2. libncurses5-dev    -- after being confused by link errors
  3. bison              -- after confusing yacc-related errors

Something else that surprised me was that it was not enough to unpack
just src.tgz, sharesrc.tgz and gnusrc.tgz:  usr.sbin/config/* needs to
be unpacked from syssrc.tgz to build the cross tools.  I unpacked all
this stuff in a directory unpack-here, and set up to put the
cross-tools at /usr/local/netbsd/tools and the later mac68k binaries
at /usr/local/netbsd/obj.  Then

[unpack-here]$ cd usr/src
[src]$ ./build.sh -u -m mac68k -T /usr/local/netbsd/tools \
	-D /usr/local/netbsd/obj -t

The only stumbling blocks were cat and sunlabel.  I think my cat is
fine, but I eventually gave up on sunlabel.  Here are the details: 

[src]$ emacs bin/cat/cat.c
## commented out the top stuff, and inserted #define EFTYPE 79
## according to NetBSD intro(2) and src/include/errno.h
## (which differed from /usr/include/errno.h for me).

[src]$ emacs usr.sbin/sunlabel/sunlabel.c
[src]$ cat usr.sbin/sunlabel/sunlabel.c
#include <stdio.h>
int main(int ac, char **av)
{ printf("Sorry, could not build sunlabel properly."); }

The showstopper on sunlabel was that my system's libutil does not
define a couple of partition-related functions that were being used.
(And why is it a cross-tool, anyway?  To burn distribution CDs?)

With those things worked around, all the tools built smoothly.  (Then
redoing it all, by using build.sh without the -u option, took the
roughly forty minutes mentioned above.)  The 750K or so of compiler
messages did include warnings, but nothing that seemed serious.

There are a lot of things that need doing with the mac68k port:

    -- build hfs support into the kernel, at least as a module

    -- package pdisk (or has that already been done?) so we get out of
       what looks like a bizarre situation of not being able to do
       disk partitioning from within NetBSD

    -- do something toward sound support

    -- improve the SCSI support

    -- get SWIM (floppy disk) support working, even if it is slow

    -- update some of the docs, including those for the existing X server

    -- get XFree86 working in some form (personally, I would wish for
       4-bit grey-scale support!)

    -- do some careful documentation of exactly how this port is
       depending on MacOS, to make it easier for somebody to remove
       the dependencies.

My plan is to fix the broken FPE.  If anybody has clues about this,
please tell me.  Something seems to have gone wrong about the time the
switch to ELF was made, and it would be interesting to know whether
anyone *not* using FPE noticed any new problems with SCSI or
otherwise.

-- 
John