On 12/15/06, Mike Stump <[EMAIL PROTECTED]> 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
