>  On Wed, Apr 18, 2007 at 07:10:00PM +0000, Marc Tooley wrote:
>  > >Fix:
>  >
>  > 	Back out the removal of the functions, I guess. Tests here
>  > indicate it seems to work just fine.
>
>  This is hardly a bug. With even older systems (pre gcc 3.3) you
> won't be able to compile the kernel - not a lot different to this
> scenario.
>
>  "build.sh tools" is your friend, sorry about the inconvenience.
>
>  Martin

I'm aware it's not a bug/malfunction. I'm also aware of build.sh. It's 
part of the reason I was forced to create another 10k build script that 
cleans up after every update/build cycle when iterating through the 
eight individual arch/version combos I track. build.sh isn't so 
friendly.

This problem was send-pr'd because:

. it's yet another barrier to classic-style kernel compilation; a 
barrier that didn't exist prior to the unnecessary removal of those 
functions.
. it increases inter-dependencies unnecessarily
. an entire tool chain shouldn't need to be rebuilt if the host machine 
provides an adequate compiler.
. make'ing manually one step harder for all machines older than.. Aug 
2006. "UPDATING" does not mention this.

In essence, this send-pr is the "I've been solving little problems like 
this for hours now. Here's the one that exceeded my patience 
threshold."

I guess my point was, why increase complexity this way? The functions 
are perhaps two lines a piece, so what is lost by making config(1) as 
self-contained as possible by rolling back part of this change? 
Honestly: ecalloc()?

Now people like me must expend additional effort to maintain a parallel 
source tree if we wish to continue building fresh kernels as documented 
here:

http://www.netbsd.org/Documentation/kernel/#how_to_build_a_kernel

... but without the enormous build.sh overhead or the enormous system 
upgrade overhead.

I'm cognisant of the risks of using an older toolchain to build a new 
software; however, since the kernel itself is essentially monolithic it 
doesn't necessarily follow that the environment should make this much 
of a difference to kernel compilation as it does to userland. 
Meanwhile, we now have a needless libutil dependency apparently in the 
name of code consolidation.

I'm not talking about prehistoric machines either. I realise there's a 
point in time prior to which it's impossible to build a recent kernel. 
Still, changes like this decrease the ability of hobbiests to 
track -current. Not all of us can afford to spend the rapidly 
increasing amount of time necessary to participate in this particular 
march of progress.

For the record, this machine can compile a -current kernel just fine. 
3.99.23 was stocked with gcc 4.1.2, and the resulting kernel (after I 
fixed config) appears to boot on the target hardware.