------- Comment #21 from ebotcazou at gcc dot gnu dot org 2006-08-07 06:11
-------
> Okay. No generic flag-tweaking support is perfectly fine. Can we either...
>
> (1) Straighten things out so that if you do have to pass a flag(s) to the
> compiler, it is passed in through CFLAGS---thus respecting standard
> flag-variable convention, or
>
> (2) Ignore CFLAGS altogether, so that libiberty isn't built with it, and CC
> becomes the only place where flags can be put in? (The thinking being, if the
> behavior's going to be broken, at least make it _consistently_ broken)
I'm not the maintainer of the build machinery so I cannot really answer.
I'd only add that the upcoming GCC 4.2 release will feature a new bootstrap
procedure (aka toplevel bootstrap) that could solve the issue. You might want
to give a try to one of the recent 4.2 snapshots and open a new PR against it
if you deem it necessary.
> This isn't just about sparc64, you know. The whole reason why this came up in
> the first place is because I'm building GCC in a custom autobuild framework,
> across a number of architectures. For every other autotoolized package, I set
> CC, CXX, {CC,CXX,CPP}FLAGS, and everything works. It's really annoying to have
> GCC, a pretty important package, so thoroughly flout the convention that all
> the other GNU toolsets adhere to.
On the one hand, and without any inflated ego :-), you cannot consider that
bootstrapping a compiler is like building any other piece of software. On
the other hand, the aforementioned toplevel bootstrap is aimed at eliminating
the peculiarities you noticed; for example, a bare "make" will automatically
perform a complete 3-stage bootstrap for a native compiler in the sense that
the end result should not depend on the bootstrap compiler anymore at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
