Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!sdd.hp.com!usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!uxh.cso.uiuc.edu!archetyp
From: archetyp@uxh.cso.uiuc.edu (Joseph R Pickert)
Newsgroups: comp.os.minix
Subject: Re: Adventures in MacMinix Kernel Building
Message-ID: <1990Nov12.164228.6181@ux1.cso.uiuc.edu>
Date: 12 Nov 90 16:42:28 GMT
References: <627@pdxgate.UUCP> <1423@ria.ccs.uwo.ca>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 43

webber@csd.uwo.ca (Robert E. Webber) writes:


>Noticed that I hadn't set the time on my Mac since the Fall time change.
>Used date as root to change it.  Date reported the new time. Logged out 
>and quit.  Rebooted and found that the change had been forgotten.

MACMINIX gets its time from the system clock when it boots.  From then
on it keeps its own time, so you can set the time that MINIX thinks it
is, but the next time you boot it reads the system time again. Set the
macintosh system time with the control panel DA and then things
will work the way (I assume) you want.

>About this time, decided to rebuild minix from source.  Started by
>running make in /usr/kernel.  Had problems with compiling idle.c, printer.c,
>rs232.c, and console.c.  Apparently the mac include files blow away the
>preprocessor stage in cc.  chmem'ing cc doesn't effect this.  chmem'ing
>/usr/lib/cpp doesn't fix this either if compiling with cc.

/usr/lib/cpp is NOT USED by the compiler.  It is there for the
convience of other programs. cpp functionality is built into /usr/lib/cem,
so that is the one you want to chmem.

>Anyway, the problem with rmaker turns out to be that sbrk will return
>odd addresses when it feels like it.  However, when this result is passed
>by from smalloc in smalloc.c (of /usr/src/commands/mac/rmaker) it gets
>used sometimes as a pointer to an aligned structure.  My fix was to
>insert
>        p = p + 4 - (((long)p) % 4);
>immediately after
>        p = sbrk(0);
>in the smalloc routine.

Sure enough this is a problem on a 68000 processor. 68020's can
do longword accesses on a short boundry, but 68000's can't.

>With this everything seemed to build ok.  By the way, a number of times
>during makes, write errors occurred during the ld phase.  Rerunning the
>make would repeat the ld and succeed the second time.  Not sure what is
>causing this problem.

Somebody else has reported this problem to me.  If anyone finds the
problem please let me know.