*BSD News Article 27110


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!hippo.ru.ac.za!ee.und.ac.za!tplinfm
From: barrett@lucy.ee.und.ac.za (Alan Barrett)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Upgrading NetBSD-0.9 to NetBSD-current HELP-HELP-HELP
Date: 12 Feb 1994 00:46:45 +0200
Organization: Elec. Eng., Univ. Natal, Durban, S. Africa
Lines: 70
Message-ID: <2jh1sl$fc5@lucy.ee.und.ac.za>
References: <2jb9qg$8lt@sundog.tiac.net>
NNTP-Posting-Host: lucy.ee.und.ac.za

In article <2jb9qg$8lt@sundog.tiac.net>,
timj@tiac.net (Tim Jackson) writes:
> I am trying to upgrade from a stock NetBSD 0.9 to NetBSD-current

I recently went through the same exercise.  I suggest that you try
something like this:

 * Start by building and installing the new make, which has some extra
   builtin variables that everything else seems to rely on.  You might
   have to hack usr.bin/make/Makefile before you can persuade the old
   make to help you build the new make.

 * Don't install the new /usr/share/mk/* stuff yet, because it has rules
   about shared libraries etc. and the old compiler can't deal with
   that.

 * Now might be a good time to build and install new versions of the
   libraries (both non-GNU and GNU).  I am not sure whether this is
   necessary, but it probably won't hurt.

 * Build and install the new linker (ld), assembler (gas) and compiler
   (gcc), in that order.  You need the new linker to handle the shared
   library support that the new compiler will want, and you need the
   new assembler to handle the ".type" directives that the new compiler
   uses.

 * This is probably a good time to install the new /usr/share/mk/*
   stuff.  Then you can do a "make clean" and rebuild all the libraries;
   this time, because of the new make rules, you will get the profiled
   and shareable versions as well as the plain versions.

 * The new compiler, linker and assembler themselves are still
   listatically nked.  You might like to rebuild them with the new
   lishareable braries.

 * Now build and install the new lex.  This will require some hacking,
   because the new lex's "scanner.l" source file is written in a
   language that the old lex doesn't understand.  The old lex will
   complain about the "<*>" in one of the rules (just delete those
   three characters to make it happy).  After fixing that, you will get
   some undefined symbols at link time; these can be fixed by adding
   appropriate stuff to the y.tab.h file that the old lex generates from
   the new scanner.l; look at the compiler or linker error messages to
   figure out what parts of the new flex.skl you should incorporate into
   the generated y.tab.h to make it work.

 * At this point, I think you can try a "make build" from the top level,
   and also build a new kernel.  Don't forget to undo any changes you
   made to the new sources.

 * I don't know how you safely install the new kernel, new boot blocks
   and new everything else.  The old boot blocks should be able to boot
   a new kerne (unless it's too large), so they are not a problem.
   The new "ps" and various other utilities don't really like the old
   kernel, and vice versa, so you may have a problem.  I had my system
   crash several times when I tried a top level "make install" while
   running an old kernel, so perhaps the new kernel should be installed
   before the new system utilities.

The above suggestions are untested.  I did not do things in the order
suggested above, but I think that I would have had a much easier time
if I had done them in that order.  For example, one of my mistakes was
to install the new gcc, without keeping a backup of the old one, only
to find that I now couldn't compile anything because I still had the
old gas that didn't understand ".type" information.  (A binary patch to
change ".type" to "#type" fixed that.)

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za