Subject: /usr/bin/cc versus stock gcc
To: None <tech-toolchain@NetBSD.ORG>
From: Brian C. Grayson <>
List: tech-toolchain
Date: 02/01/1997 18:44:25
  (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

  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
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/
gcc version

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 Grayson (
Graduate Student, Electrical and Computer Engineering
The University of Texas at Austin
Office:  ENS 406       (512) 471-8011
Finger for PGP key.