On Tue, 30 Dec 2003, Gordon Zaft wrote:
> --- Brian Chase <vaxzilla@jarai.org> wrote:

> > For the purists, here are the results of my first
> > native build of
> > the -current sources as painstakingly compiled on a
> > VS4000/VLC.
> >
> >   http://www.vax.org/temp/20031227-1/vax/
>
>  Can you share what you had to do to get it to build?

Hehe.  Well, it was quite an ordeal, but in a nutshell: First I
downloaded the August i386 snapshot release of -current, then
I compiled and installed my own release of -current for i386.
Next I cross-compiled a VAX binary release on my i386 system and
installed this on my VS4000/VLC.  Then I recompiled a -current
release natively on the VAX.

The native VAX compile was not without its headaches.  Let's see if I
can remember all the steps that I took.  You may vary these as
appropriate for your specific needs:

[1] Perform a cvs checkout of -current.

[2] Create a /usr/snapshot dir to hold the resulting release.

[3] Manually create an `obj' dir in the `src' directory.  At least I
    found that you have to do this if you let the build.sh script
    automatically handle setting things like TOOLDIR.  The build.sh
    script, IMHO, exhibits broken behavior when left to its own devices
    in a pristine src directory.

[4] Rename the `regress' directory to `regress.skip' (or alternatively,
    according to Matt Thomas, give the build.sh script the
    `-V BUILD_regress=NO' option).  The regression tests don't build
    correctly, so you have to get past them for things to succeed.

[5] Run the following command:

    ./build.sh -V CHECKFLIST_FLAGS="-e -m" -R /usr/snapshot release'

    This eventually crashes when pic.ps fails to be properly built,
    leaving behind a zero-length pic.ps file.

[6] Restart the build with:

    ./build.sh -o -u -V CHECKFLIST_FLAGS="-e -m" -R /usr/snapshot release'

    This eventually crashes a little further along when grnexmpl.ps
    fails to build, but leaves behind a zero-length grnexmple.ps file.

[7] Restart the build with:

    ./build.sh -o -u -V CHECKFLIST_FLAGS="-e -m" -R /usr/snapshot release'

    For some reason, my compile for robots/move.o died with:
    vax--netbsdelf-gcc: Internal compiler error: program cc1 got fatal
    signal 11.  Solar flares, perhaps?

[8] Restart the build with:

    ./build.sh -o -u -V CHECKFLIST_FLAGS="-e -m" -R /usr/snapshot release'

    This time robots/move.o compiled successfully and the build of the
    release made it all the way to completion.

It took about 15 days for my VLC to get from step 5 to step 8.  And it
was another two weeks worth of effort prior to that for me to get my
cross-compile environment up to speed to generate a first pass VAX
-current release.

So far I've only verified that my builds are running smoothly on two of
my VS4000/VLCs.  The 1.6ZG kernel panics when it first tries to access a
SCSI disk on both MicroVAX 3100/20e and VAXstation 3100/M76.  I still
need to put together a more extensive testbed setup.  In the meantime,
I'd appreciate it if some other people could report how the build runs
on some of the other VAXen out there.

I've some suspicions about the panics in 1.6ZG being related to the
driver for the NCR 5380 based SCSI controllers.  That's based solely on
the fact that the systems which have the SCSI related panics both use
the 5380 chipset.  The system that's working fine uses an NCR 53C94.
Okay, so it's a weak hypothesis as best, given the limited number of
datapoints it's based on.

-brian.