Subject: Guide to updating to current from 1.2 (was Re: trying to compile
To: Scott Stevens <s.k.stevens@ic.ac.uk>
From: Chris Gilbert <cg110@york.ac.uk>
List: port-arm32
Date: 06/09/1997 11:53:50
I thought this might be of interest to people (might save some wasted
time, note that I've spent a lot of time playing with current from 2-3
weeks ago to get a smooth compile, and this is what I came up with) 
This guide is unplanned and I've only just written it.  It is by no
means complete but should let ppl get somewhere with compiling.  I did
this more out of interest and lots of free cpu time, as I had revision
for exams so it seemed perfect for leaving it compiling.

Problems I had are mentioned in the steps or at the end, as some occured
in lots of places.

Select a place to use for placing the new includes and libs, I choose
/new as it was an empty HD, I don't recommend installing over the top of
your present system, it also avoids having sync probs if you need to
compile something else half-way through doing a build.

Step 1: get complete current source tree (only if you want the new
binaries, otherwise the parts you need, note that libl needs
usr.bin/lex) and install in usr/src, one you can miss is games.tar.gz
Step 2: build a new make, then cd src/share/mk and make install as root
(this will give you new mk files in ${DESTDIR}/usr/share/mk)
Step 3: edit /usr/share/mk/bsd.own.mk, and look for the section that
says these architectures don't support pic, and add '||
(${MACHINE_ARCH}=="arm32")' to it somewhere, this cures building of pic
and so versions.  Also alter anything else you need to (eg symlinks for
the sys headers into /usr/include)

Note you cannot install new usr/share/mk without a new make as old make
can't use new .mk files.

Step 4: build new version of config and install.
Step 5: build a new kernel, and install as normal.

Step 6: cd src/sys and make includes, this gives you uptodate include
files for the machine dir and a few others.
Step 7: This part I don't really know about but it seems to cure some
problems:
	you need to build new versions of: ar, nm, ranlib, gcc, and ld  These
will be built against your present libs (you rebuild them later against
the new libs)  and install them, a new gcc is needed to do libg++ (I
think that's what it's called..)

Step 8: Ok now it's time to select where you want the new files, I
choose /new.  once decided 'setenv DESTDIR /new' (replace /new as
appropriate)

You're now ready to deal start building current, this is a tedious
process as running make depend won't depend against DESTDIR/usr/include
:(.

Step 9: cd src/etc and type make distrib-dirs, this puts all the needed
dirs into DESTDIR

Step 9b: You might want to cd src and type make cleandir which cleans
everything, or you can just make cleandir for nm, ar, ranlib, gcc and
ld,  and skip doing the whole tree.  Cleaning nm, ar, ranlib, gcc and ld
is needed.

Step 10: cd src and make includes, this will take a while as it scans
all the dirs for the includes (note that some are in strange places)
Step 11: cd src/lib/csu and make, (I have a feeling something went wrong
in src/lib/csu/c++ and you need to edit the Makefile, I think it tried
to build a pic version) and make install, this installs the run time C
stubs (or at least I think that's what they are ;)

Step 12: cd src/lib and make (this will take a while) you shouldn't have
any problems with the __warn_references() problem as the new ld copes :)
Step 13: make install the above, this installs the libs and man pages
(note if you put NOMAN= in bsd.own.mk you don't get man pages, if you
put  NOPROFILE you don't get profiled libs)
step 13a: cd src/gnu/lib and make, then make install, this makes new
libgnumalloc and libg++

Step 14: You should now have populated /new/usr/include and /new/usr/lib
with all the files you need. So time to start on the source tree.
Step 15: cd src and make.  This will do the complete tree, all the
binaries.  once done you should have working binaries in the relevant
files.

Step 15a: you may want to install the binaries into /new, however you
can test them easily by cd'ing to a dir and running the executable.

Step 16: Time to install over your present system. Unset DESTDIR (don't
know how so I logged out and back in) cd src and type make install (this
may or may not work! :)  on my system it failed!, so I had to go into
each dir, the order is lib, include, bin, libexec, sbin, usr.bin,
usr.sbin, share, games (if present), and gnu and type make install. 
This installs all the binaries into your system.

Step 17: Next you need to install the new etc files.  To do this cd etc,
and edit the Makefile, in distribution comment out the line for make
install.  Then do a make distribution, this will run distrib-dirs across
your present system and install the include and binary files and then
proceed to install the new etc files.

Step 18: Play with the new /etc files until you're happy they work :)

Step 19: You might want to reinstall everything again by building with a
current system, however it takes time to do.  You can now use make
depend and start supping files :)  Note that you can now use make build
safely now as the changes aren't so big.

Problems you might have.
Files fail to compile with an error code xx:
Cure:	take the compile line shown and remove the -O flag, and compile
the file, (you need to cd into the relevant dir)
	ld -x -r (file).o, this removes local labels,
	mv a.out (file).o (ld -x -r makes an a.out file)
	If this doesn't compile then a possible problem is that something is
wrong with the gcc build :( try recompiling gcc, and try making the file
again.

Warning: result is always 1 due to range of type (or some error like
that)
	This problem occurs in bin/sh and a few other places.  The error is
caused by the file expecting signed chars, arm32 is the only gcc using
system for netbsd that uses unsigned by default, amusingly bin/sh is
meant to detect type, and even prints 'unsigned 8 bits chars'.
Cure:	Take the compile line and remove the -Werror part, this lets the
file compile, then do 'ld -x -r (file).o', 'mv a.out file.o'
	Another idea is to use -fsigned-chars in the compile line, but I
decided that this is probably wrong as I'd think it requires the whole
binary to be compiled with -fsigned-chars

Error: cannot find link.h
	This is used for ld (AFAIR) and as such is found in src/gnu/lib/ld/rtld
somewhere, which isn't compiled for arm32 and is therefore missed in
make includes.
	You need to copy link.h into DESTDIR/usr/include, for building, and
then into /usr/include for the installing onto the system.

This guide is by no means complete and not for the beginner, standard
disclaim applies.  IE moving from 1.2 to current is tricky, and can go
wrong, and you need a certain amount of knowledge to solve problems in
it, if it all goes wrong do I don't take responsibilty, I've got my
system running 1.2-current now, but have a few probs with gcc :(  Given
more time I might be able to make this guide clearer.

s.k.stevens@ic.ac.uk wrote:
> 
> Jasper Wallace writes:
>  >
>  > jasper@quatermass:/usr/src/lib/libc/> make all
>  > cc -O -DNLS -DYP -D_REENTRANT -I/usr/src/lib/libc/include -D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -DFLOATING_POINT   -c /usr/src/lib/libc/yp/xdryp.c
>  > collect2: ld terminated with signal 11 [Segmentation fault], core dumped
>  > /usr/bin/real-ld: warning: this program uses xdr_domainname(), which is deprecated and buggy.
>  > /usr/bin/real-ld: warning: this program uses xdr_peername(), which is deprecated and buggy.
>  > /usr/bin/real-ld: warning: this program uses xdr_mapname(), which is deprecated and buggy.
>  > *** Error code 127

Is cured by compiling new ld.

>  > (i was compiling libc for the md5 stuff which is wanted by the new xntp
>  > stuff 'cos i wanted to use xntpd and ntpdate. Oh well back to rdate)

see guide above for the order to do things.

>  > Oh. bsd.lib.mk trys to -fpic everything and to produce lib.so.0.0's which
>  > dies a little.

This is because bsd.own.mk is wrong.

>  > but at least i've got pine, procmail, and exim working nicely together ;-)
> 
> This is an obscure problem, but there is a work around. Edit the
> offending file removing some of the __warn_references() calls. The
> linker seems to be fine with one or two, but dies with a few more...

It seemed to occur in files with just one __warn_references().  I'd
recommend making a new ld, and leaving them in.
 
Hope this helps in some way,

Chris