Subject: toolchain/18270: Kernel builds from handle COPTS wrong.
To: None <>
From: None <>
List: netbsd-bugs
Date: 09/11/2002 23:49:03
>Number:         18270
>Category:       toolchain
>Synopsis: -R builds release kernels, but does so with wrong COPTS if COPTS are set in mk.conf.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 11 16:50:00 PDT 2002
>Originator:     Thor Lancelot Simon
>Release:        NetBSD-current, i386, sources from anoncvs 2002-09-11
The NetBSD Foundation
NetBSD enola-gay 1.6H NetBSD 1.6H (ENOLA-GAY) #8: Wed Sep 11 16:54:16 EDT 2002     root@enola-gay:/usr/src/sys/arch/i386/compile/ENOLA-GAY i386
Architecture: i386
Machine: i386
>Description: -R automatically builds the kernels required for a release
distribution of NetBSD (on i386, sundry GENERIC and INSTALL kernels).  But
if COPTS is set in /etc/mk.conf -- even if it's set with +=, not =, which
is the standard, documented way to add compiler flags to the system build --
something goes awry in the build machinery and no optimization at all is
used for the kernel builds.

For example, if I build a release with:
COPTS+=-mcpu=pentiumpro -march=pentiumpro
in my /etc/mk.conf, the rest of the tree is correctly built with the
default optimization (-O2 on i386) *and* -mcpu=pentiumpro -march=pentiumpro.
However, the kernels are built with no -O flag at all; just -mcpu=pentiumpro
-march=pentiumpro.  This is equivalent to -O0, which is problematic since we
seldom if ever test -O0 kernels and even the toolchain itself is poorly
tested at -O0.

Clearly, if COPTS is going to be honored at all for kernel builds (at
one point, it was not; explicit "makeoptions=" was required in the kernel
config file to set compiler options for a given kernel build) it needs
to be used in the same way as for the rest of the system build.

Insert COPTS+=-mcpu=pentiumpro -march=pentiumpro in your /etc/mk.conf and get to try to build some kernels.  At present, it will explode building
GENERIC due to a -O0 -march=pentiumpro bug in our gcc (see separate PR)
which is rather illustrative of the problem.