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