(This is a more-current version of a message I had tried to
post to this list a few times in the past.  I don't think the
earlier versions made it through.  Anyway, this supersedes
them.)

  On -i386, running mostly current (from mid Jan), compiles need
to use /usr/bin/cc for compiling both kernels and part of
libgcc -- a stock gcc installation (which we need for various
reasons) can not be used.

  1.  In the kernel source:  Several months ago (if I'm interpreting
this correctly), all references to kprintf were removed from
the kernel, and all code that used the special-purpose formats
(%:, %b, et al?) was rewritten to use a helper function.
However, since then, some use of these formats have crept back
in, e.g. subr_prf.c:126 uses the %: format.

  2.  In userland, building /usr/src/gnu/usr.bin/gcc/libgcc/ results
in the following for _op_new.o, _op_delete.o, _op_vnew.o, and
_op_vdel.o:
cc -O -I/usr/src/gnu/usr.bin/gcc/libgcc/../common \
  -I/usr/src/gnu/usr.bin/gcc/libgcc/../arch \
  -I/usr/src/gnu/usr.bin/gcc/libgcc/../arch/i386  -Werror  -c \
  -DL_op_new -o _op_new.o /usr/src/gnu/usr.bin/gcc/libgcc/libgcc2.c
cc1: warnings being treated as errors
/usr/src/gnu/usr.bin/gcc/libgcc/libgcc2.c:1652: warning: alias
definitions not supported in this configuration

gcc -v returns:
Reading specs from /usr/local/lib/gcc-lib/i386-unknown-netbsd/2.7.2.1/specs
gcc version 2.7.2.1

which is "stock" gcc.  Running "make CC=/usr/bin/cc" works fine
to solve both problems.

  Part of the problem stems from the fact that /usr/local/bin is
in our root's path before /usr/bin -- I'm guessing this local
policy was done because we needed gcc-2.7 for various projects when
-current was 2.5.8, or 2.6.2 or whatever.  It's probably an
obsolete policy, and should be changed.  However, from an
aesthetic viewpoint, it would be nice if kernels and userland
could be compiled by stock gcc -- this would make
cross-compiling a bit easier, for example.

  Is anyone else concerned with "stock" compilability(?), as far as
possible?  Is core?  :)  Are these things PR-worthy?

  I'd be willing to track/find such incompatibilities for
-i386, if it would be worthwhile.

  Brian
-- 
Brian Grayson (bgrayson@ece.utexas.edu)
Graduate Student, Electrical and Computer Engineering
The University of Texas at Austin
Office:  ENS 406       (512) 471-8011
Finger bgrayson@orac.ece.utexas.edu for PGP key.