Subject: Re: building -current, CPU optimizations, and the 'sh' problem.
To: None <port-sparc@NetBSD.org>
From: John D. Baker <firstname.lastname@example.org>
Date: 10/18/2005 16:08:01
My SS5-110/256MB finished completely rebuilding -current from a source
tree updated sometime on 14 October. Everything was built with:
The 'sh' used during the build of the kernel and userland was the one I
built separately with "DBG=-g". The new userland was installed immediately
after the build and the machine was rebooted. The just-installed 'sh' was
then used during the build of the release sets. No core files were
observed following the build of any of the system components.
I then went on to build a few packages from pkgsrc. 'digest', 'libtool-base',
x11-links, xpkgwedge, and rxvt all built and installed without any problems.
I then set about building wm/fluxbox. The dependency 'gmake' appeared to
build and install without problems, but I just found an 'sh.core' file in
the work directory once it all finished.
'fluxbox' itself failed to build because it couldn't find some of the
X11 header files even though the -I directives specified the root path
to them. For some reason:
ln -s /usr/X11R6/include/X11
allowed it to build without error. I'm not sure if this is a glitch
in my X11 base installation/upgrade, or if I caught pkgsrc in the middle
of a rearrangement of some X11-related packages. fluxbox built without
problems (with the debug 'sh') just before I rebuilt the world.
Further examination also revealed an 'sh.core' file in fluxbox's work
directory. Whatever happened it didn't seem to affect the build process
of either 'gmake' or 'fluxbox'. 'fluxbox' appears to operate just fine.
There was mention of how one can add the '-g' switch to get debugging
symbols without otherwise disturbing the code generation? I'll see if
I can rebuild my 'sh' that way to collect more data on the problem.
John D. Baker, KN5UKS NetBSD Darwin/MacOS X
jdbaker(at)mylinuxisp(dot)com OpenBSD FreeBSD
BSD -- It just sits there and _works_!