> It might be useful if you documented exactly what you did. This is
> likely to be a very popular topic for the next few months...
Not quite possible, because when things started to look foobar I was
not cool enough to keep logging. :)
But I know some highlights of my tour:
o My Last successful -current build was
Sun Sep 19 19:18:42 CEST 1999
o Then I tried to rebuild on
Tue Oct 5 17:49:53 CEST 1999
and got this one:
===> f77doc
/usr/obj/usr/src/gnu/usr.bin/cc/f77doc created for /usr/src/gnu/usr.bin/cc/f77doc
cd /usr/src/gnu/lib/libgcc; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO
-DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend; /usr/obj/usr/src/tmp/usr/bin/make
-DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED all;
/usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE
-DNOSHARED -B install; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN
-DNOPROFILE -DNOSHARED -B cleandir obj
rm -f .depend /usr/obj/usr/src/gnu/lib/libgcc/GPATH
/usr/obj/usr/src/gnu/lib/libgcc/GRTAGS /usr/obj/usr/src/gnu/lib/libgcc/GSYMS
/usr/obj/usr/src/gnu/lib/libgcc/GTAGS
echo '#include <i386/xm-i386.h>' > config.h
echo '#include <xm-freebsd.h>' >> config.h
echo '#include "i386/xm-i386.h"' > tconfig.h
echo '#include "i386/i386.h"' > tm.h
echo '#include "i386/att.h"' >> tm.h
echo '#include "i386/freebsd.h"' >> tm.h
echo '#include "i386/perform.h"' >> tm.h
cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config
-I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC
-I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o
/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c
*** Signal 12
Stop in /usr/src/gnu/lib/libgcc.
So I decided to wait some times, in case this was related to
changes to gcc.
o Next try was
Sun Oct 10 12:55:50 CEST 1999
This time I had a look into freebsd-current and src/UPDATING before
and noticed that I had to build a new kernel before.
No problems. Kernel compiled, installed and booted.
o Later,
Sun Oct 10 13:38:40 CEST 1999
during make buildworld, I got this one:
cc -O -pipe -I/usr/src/usr.bin/make -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/usr.bin/make/arch.c
In file included from /usr/include/sys/stat.h:50,
from /usr/src/usr.bin/make/arch.c:97:
/usr/include/sys/time.h:289: time.h: No such file or directory
/usr/src/usr.bin/make/arch.c:100: ctype.h: No such file or directory
/usr/src/usr.bin/make/arch.c:101: ar.h: No such file or directory
/usr/src/usr.bin/make/arch.c:102: utime.h: No such file or directory
/usr/src/usr.bin/make/arch.c:104: stdlib.h: No such file or directory
In file included from /usr/src/usr.bin/make/arch.c:105:
/usr/src/usr.bin/make/make.h:53: ctype.h: No such file or directory
/usr/src/usr.bin/make/make.h:76: stdlib.h: No such file or directory
In file included from /usr/src/usr.bin/make/make.h:80,
from /usr/src/usr.bin/make/arch.c:105:
/usr/src/usr.bin/make/lst.h:51: stdlib.h: No such file or directory
/usr/src/usr.bin/make/arch.c: In function `ArchStatMember':
/usr/src/usr.bin/make/arch.c:464: `SARMAG' undeclared (first use in this function)
/usr/src/usr.bin/make/arch.c:464: (Each undeclared identifier is reported only once
/usr/src/usr.bin/make/arch.c:464: for each function it appears in.)
/usr/src/usr.bin/make/arch.c:468: storage size of `arh' isn't known
/usr/src/usr.bin/make/arch.c:514: storage size of `sarh' isn't known
/usr/src/usr.bin/make/arch.c:540: `ARMAG' undeclared (first use in this function)
/usr/src/usr.bin/make/arch.c:552: sizeof applied to an incomplete type
/usr/src/usr.bin/make/arch.c:553: `ARFMAG' undeclared (first use in this function)
/usr/src/usr.bin/make/arch.c:621: sizeof applied to an incomplete type
/usr/src/usr.bin/make/arch.c:623: sizeof applied to an incomplete type
/usr/src/usr.bin/make/arch.c: In function `ArchFindMember':
/usr/src/usr.bin/make/arch.c:785: `SARMAG' undeclared (first use in this function)
/usr/src/usr.bin/make/arch.c:798: `ARMAG' undeclared (first use in this function)
/usr/src/usr.bin/make/arch.c:814: dereferencing pointer to incomplete type
/usr/src/usr.bin/make/arch.c:815: dereferencing pointer to incomplete type
/usr/src/usr.bin/make/arch.c:818: sizeof applied to an incomplete type
/usr/src/usr.bin/make/arch.c:819: dereferencing pointer to incomplete type
/usr/src/usr.bin/make/arch.c:819: `ARFMAG' undeclared (first use in this function)
/usr/src/usr.bin/make/arch.c:819: dereferencing pointer to incomplete type
/usr/src/usr.bin/make/arch.c:826: dereferencing pointer to incomplete type
/usr/src/usr.bin/make/arch.c:834: dereferencing pointer to incomplete type
/usr/src/usr.bin/make/arch.c:834: dereferencing pointer to incomplete type
/usr/src/usr.bin/make/arch.c:844: sizeof applied to an incomplete type
/usr/src/usr.bin/make/arch.c:890: dereferencing pointer to incomplete type
/usr/src/usr.bin/make/arch.c:890: dereferencing pointer to incomplete type
/usr/src/usr.bin/make/arch.c:891: dereferencing pointer to incomplete type
/usr/src/usr.bin/make/arch.c: In function `Arch_Touch':
/usr/src/usr.bin/make/arch.c:924: storage size of `arh' isn't known
/usr/src/usr.bin/make/arch.c:935: sizeof applied to an incomplete type
/usr/src/usr.bin/make/arch.c: In function `Arch_TouchLib':
/usr/src/usr.bin/make/arch.c:961: storage size of `arh' isn't known
/usr/src/usr.bin/make/arch.c:962: storage size of `times' isn't known
/usr/src/usr.bin/make/arch.c:968: sizeof applied to an incomplete type
/usr/src/usr.bin/make/arch.c: In function `Arch_MTime':
/usr/src/usr.bin/make/arch.c:1006: dereferencing pointer to incomplete type
/usr/src/usr.bin/make/arch.c: In function `Arch_LibOODate':
/usr/src/usr.bin/make/arch.c:1170: dereferencing pointer to incomplete type
*** Error code 1
o Next try was weeding out /usr/include and /usr/share/misc
(with the occasional cd /usr/src/include; make install) and a
make world -DCLOBBER on
Sun Oct 10 16:38:03 CEST 1999
that ended here:
cc -O -pipe -I/usr/src/usr.bin/make -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/usr.bin/make/compat.c
In file included from /usr/src/usr.bin/make/compat.c:67:
/usr/include/signal.h:80: syntax error before `*'
/usr/include/signal.h:84: syntax error before `*'
*** Error code 1
o Then came a make world -DNOTOOLS -DCLOBBER on
Sun Oct 10 16:39:35 CEST 1999
that stopped here
Processing hints file hints/freebsd.pl
Writing Makefile for POSIX
mkdir /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX
mkdir /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/auto
mkdir /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/auto/POSIX
cd ext/POSIX; make -B all PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl
cp POSIX.pod /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/POSIX.pod
cp POSIX.pm /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/POSIX.pm
AutoSplitting /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/POSIX.pm
(/usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/auto/POSIX)
/usr/bin/miniperl -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib
-I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib
/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/ExtUtils/xsubpp -noprototypes -typemap
/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/ExtUtils/typemap -typemap typemap POSIX.xs
>xstmp.c && mv xstmp.c POSIX.c
cc -c -DSTRUCT_TM_HASZONE -DVERSION=\"1.02\" -DXS_VERSION=\"1.02\" -DPIC
-fpic -I/usr/obj/usr/src/gnu/usr.bin/perl/perl POSIX.c
In file included from POSIX.xs:31:
/usr/include/signal.h:80: syntax error before `*'
/usr/include/signal.h:84: syntax error before `*'
*** Error code 1
o Can't remember what I did in what order exactly then, but it
involved moving back to a tree that I believed to work
(cvs update -D "14 Sep 1999"), diffing and copying headers
in /usr/include and stuff in /usr/lib. Note that I kept the
new kernel from Oct, 10th! Also some partial installs,
when compilation hanged.
Finally compilation went through. So I used that userland
(that worked except for stuff like top and ps) to get the source
tree from Oct, 11th and to finally compile that, after some
obstacles.
E.g. compilation broke off during build of kdump and ktrace.
I finally hacked their makefiles to jump over them, to
get a nearly complete Oct, 11th user land compiled.
And it worked. Reboot and new kernel compilation worked too:
-r-xr-xr-x 1 root wheel 1770088 Oct 11 22:51 kernel
-r-xr-xr-x 1 root wheel 1770088 Oct 10 13:13 kernel.old
-r-xr-xr-x 1 root wheel 1761443 Sep 19 21:11 kernel.ORANJE
Same size, not bad.
> As for obsolete cruft in the root and /usr filesystems, you could try
> "rm -fr /" :-). Seriously, since installworld installs everything
> with the current date, one way is to run "ls -ltr" on all all affected
> directories and delete all files older than the installworld.
In my case the old cruft had no effect during the last build,
but then managed to sabotage the build of the latest system.
Today, after a hint from Jörg Wunsch to use ktrace for resolving
my trouble with emacs, I tried to recompile ktrace and kdump,
ran again into trouble and then realized (after looking at the
history with cd /usr/src/sys/netinet; cvs log ip_fil.h etc)
----------------------------
revision 1.8
date: 1999/10/10 15:09:53; author: peter; state: dead; lines: +1 -1
Nuke the old antique copy of ipfilter from the tree. This is old enough
to be dangerous. It will better serve us as a port building a KLD,
ala SKIP.
The hooks are staying although it would be better to port and use
the NetBSD pfil interface rather than have custom hooks.
----------------------------
that these headers
ip_compat.h
ip_fil.h
ip_frag.h
ip_nat.h
ip_proxy.h
ip_state.h
ipl.h
were obsolete and their existence prevented the kdump build.
And you can't nuke /usr/include in advance, as you need it
to build the new system.
> I have had a couple of occurrences where my checked-out source tree
> got out of step with my CVS tree (I'm not sure how this happened).
> My solution here is to occasionally do a checkout into a temporary
> tree and compare it with my active tree.
> (An alternative would be to squirrel away my local patches and blow
> away the active tree).
I really wonder how our hardcore coders manage large sets of
patches during their development phase.
Sounds like a job for cvs, or?
AFAIK, in cvs theory I would have my local cvs repository and would
operate it with at least two branches.
A vendor branch, were I would import the stuff I get from vendor
FreeBSD.org and the main trunk, were I grow my version of the source
tree.
So I could use cvsup to checkout the latest tree from FreeBSD.org
into some directory and import that one with a cvs import command.
No clue how long that would take with such a large tree.
If it is comparable to a cvs update, it will take 30min-1h for all
stuff (doc,ports,src,www) on my box.
I also can't say how many conflicts will arise, if that new stuff
hits local modifications. If I would import on a daily base, would I
need to resolve conflicts again and again?
Anyway. That would give me the sources only.
[Warning: long blurb - will get recycled see below :) ]
One of the best things that happened to me in the last months
regarding FreeBSD development was switching CVSup usage from
mirroring the latest tree (thus having only the head revision for
every source) to mirroring the CVS archives at FreeBSD.org
This gives me access to
a) all revisions of a file, and -also very important-
b) access to the checkin comments of the commiters.
The first case is what made me originally switch.
I use Hellmuth Michaelis i4b package to connect to the Internet via
ISDN. This is usually working so excellent that I never took the time
to install ISDN drivers to that Windows 95 system that is also on my
disks.
However FreeBSD and i4b were changing in a way last year, that often,
after updating a nice working source tree over the Internet and
recompiling I ended up with a system that was (among other things)
broken in a way that it was not able anymore to connect to the net.
Bad situation because I had only the latest tree on my disk, and
could not revert easily (= via the net) to a working tree. So I
usually installed an older FreeBSD version from CD-ROM then and
started over. That was quite an act sometimes (sd->da, aout->elf..)
Then I realized that I need the CVS repository on my box, and with
help from John Polstra I configured CVSup to mirror it.
Since then I can use cvs log and cvs status to see the history
and read the committer's comments. Very useful.
Drawback is speed. While CVSup mirrors the CVS repository quite fast
I now need an additional cvs update to sync my source tree with the
CVS repository. And that is quite slow. (But I am working on a
program that will speed up this process)
[end of blurb - back to administering patches]
So, how to get the comments into the cvs repository?
Possible sources are
- the commit messages from the cvs-all mailing list
(local copy, or accessed from www.freebsd.org)
- the FreeBSD CVS repository itself (local mirror as described above,
or accessed from the anoncvs server at FreeBSD.org)
It should be possible building such a system, with lots of duct tape.
Question is -and that is the reason I went into such detail here-
is this a too complicated solution for managing an individual tree
while staying in contact with the main tree, or might it be useful?
I hope for some criticism by the folks here, and will experiment
further and hope to finally write it up.
Regards,
Marc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
