This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question on BOOT_CFLAGS vs. CFLAGS
On 12/15/06, Mike Stump <mrs@apple.com> wrote:
This proves the necessity of two different controls, namely
BOOT_CFLAGS and STAGE1_CFLAGS. I don't propose getting rid of those
or removing them. What it doesn't show is why CFLAGS can't always
influence the build product (as long as BOOT_CFLAGS isn't set, of
course). A setter of CFLAGS promises to not use it when it isn't
applicable, any time those options would not be valid for both the
bootstrap and the stage[23] compiler, they promise not to use that
control.
But wait, most people don't read the documentation anyways. So if you
have BOOT_CFLAGS be set by CFLAGS, then we end up with bug reprots
about trying to bootstrap GCC with say ICC and the options of ICC not
working at the second stage.
This is true of either way BOOT_CFLAGS is set or not, but maybe the
current way is better for people who don't read the documentation
because it means less build failures.
mrs $ make CFLAGS=-O2
stage1 builds with -O2
stage2 builds with -O2
This is not my problem with what you think BOOT_CFLAGS should be set
from CFLAGS, it causes normal build failures where some enivornent
variable was just set by the system admin by default, and yes this has
shown up in the past.
Witness the comment in http://gcc.gnu.org/install/build.html:
Note that using non-standard CFLAGS can cause bootstrap to fail if
these trigger a warning with the new compiler. For example using `-O2
-g -mcpu=i686' on i686-pc-linux-gnu will cause bootstrap failure as
-mcpu= is deprecated in 3.4.0 and above.
Thanks,
Andrew Pinski