cgd writes:

>Not so 'odious,' of you realize that:
>        (1) one can't build 'kernel libraries' in a
>                machine-independent place without special
>                support for pulling in machine-specific options
>                (e.g. things dealing with global pointers, FP
>                regs, etc.), and,

But it *used* to work, didn't it?? I had an ``obj.pmax'' in libkern,
and pmax kernel libraries got made there quite happily.

Did you mean more specific than that?  Or is the issue pulling in the
right options, e.g,. for CFLAGS?  If so, why can't the make of the
kernel libraries inherit it from the main kernel Makefile??

>       (2) having the libraries compile with different flags _per
>                kernel_ is a useful feature.

More flags than profiled or not??   Well, if you say it's useful,
it's useful.

>i looked at the libc path lines, and i'm not at all sure why they
>should be there, at all.

I assumed someone was trying to clean up libkern, and use libc library
functions, where appropriate (e.g., the fns are leaf fns, and
originally derived from the same source), and didn't quite get it
right.

I took it as read that the change I suggested was going to break that,
if so -- until ``redundant'' libkern sources are removed, anyway.  But
I beleive my change is correct: libkern needs to be be able to provide
source for functions that override the libc source.