version=3.0.3
Sender: port-i386-owner@NetBSD.org

Quoting Perry E. Metzger (perry@piermont.com):
> 
> Douglas Wade Needham <cinnion@ka8zrt.com> writes:
> > Quoting Perry E. Metzger (perry@piermont.com):
> >> 
> >> Douglas Wade Needham <cinnion@ka8zrt.com> writes:
> >> > My latest pkgsrc build, with pkgsrc updated to a Jan 12 (from the
> >> > trunk), completed in 99304 seconds.  Same base 3.0 build (so same
> >> 
> >> As I said... WHAT VERSION OF THE COMPILER. Newer versions of gcc are
> >> dramatically slower.
> >
> > Well, I had figured that since I said that I had built the 2.1 release
> > and the 3.0 release from cvs using build.sh,
> 
> build.sh's first step is to build the compiler suite in the source
> tree and use *that* to build everything else. The compiler version in
> the hosting system is irrelevent since it is only used for bootstrap...

Known and agreed.  Given that most of the time when I am building the
base OS, I am now building something like 7 ports, I am glad it
handles that headache for me. 8D But the message I sent was wrt
building pkgsrc on the system, which is well past the stage where
build.sh was involved, we were back to talking about the base NetBSD
release.  In my case, the only oddity is that I build within a
chrooted environment where the system is running a kernel for the
target revision with possibly the binaries, files, etc. from the
previous release **outside** of the sandbox into which the build was
chrooted.

> > and that the pkgsrc
> > builds were done chrooted into these trees that you might have deduced
> > that I was using the officially released versions.  But, I guess not
> > (or you are quintuple checking), so here are the versions
> 
> Are those the versions of the compilers in the tool directories or the
> versions in the hosting system?

Those are the versions which would be found in the respective comp.tgz
for the target release, which was built by the build.sh script when I
built the release, destdir, etc.  I take the destdir used to build the
release archives, copy it into a different directory, add appropiate
changes to master.passwd, etc. and end up with my chroot sandbox.  Add
src, xsrc and pkgsrc along with my previously loaded distfiles (this
was using union mounts, but at some point during the build of all the
packages, I am almost guarenteed to panic the system, so this is now a
copy), chroot, and start cd'ing into the various packages in my list
and doing make installs...

If you want to see all the magic performed by the guy behind the
curtain, feel free to take a look at my build wrappers.  The one in
question which was running so bloody long was mk_pkgs.chroot.sh, which
was called by mk_pkgs.sh.  It works on an area built using do_build.sh
which calls sysinst_cp.sh (which does lots of its magic by chrooting
and running sysinst.chroot.sh).  You can find all the necessary files
via this URL:

    http://www.ka8zrt.com/cgi-bin/cvsweb.cgi/netbsd_build/?only_with_tag=netbsd-3-0

Apologies for the speed, the dual-P90 system it is running on is
quite old, having been long since retired from duty at CompuServe ;)
I just have not had a chance to get yet another Athlon system to
replace it, and have not managed to move some stuff to the machine
which handles my Zope server...

> Anyway, I've checked (since I didn't remember) and it appears that we
> haven't gotten a compiler upgrade in some time -- in particular, 2.0
> was released with the current compiler. That means that my hypothesis
> is wrong. The performance drop from 1.6 to 2.0 was the compiler, but
> this is likely something else.

Definitely agreed, and I think it is something which is transient, but
can occur soon after reboot.

- Doug

-- 
Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own.  Since I don't want them, why
            should my employer, or anybody else for that matter!