--- Comment #26 from ebotcazou at gcc dot gnu dot org 2006-08-07 07:56
---
> Does all that sound good? Can we at least agree that the aforementioned
> inconsistency is a bug, even if the build system is too hopelessly complex to
> fix it, and 4.2 might not even have this issue anymore?
--- Comment #25 from skunk at iskunk dot org 2006-08-07 07:42 ---
(In reply to comment #24)
> Of course you can override them on the line of the "make" command.
Right, but that's getting into mucking-with-the-build territory. (Hence my
tongue-in-cheek reply to Andreas in comment #4... i
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2006-08-07 07:04
---
> I think you meant to say, "not depend on the native compiler" :-)
Yes, the bootstrap compiler is the compiler you start the bootstrap with.
> Right, but... of course, whenever I say that I set such-and-such f
--- Comment #23 from skunk at iskunk dot org 2006-08-07 06:43 ---
(In reply to comment #21)
> 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.
Very interesting. I'll have a look at it. If this re
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-08-07 06:23
---
> 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 a
--- 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 respec
--- Comment #20 from skunk at iskunk dot org 2006-08-07 05:51 ---
(In reply to comment #19)
> Everything is always doable if resources permit. Tweaking CFLAGS is simply
> not generically supported and I don't think we have plan to that effect.
Okay. No generic flag-tweaking support is
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-08-07 05:32
---
> Now, if the failure was in linking code built with xgcc against the original
> [cc-built] libiberty, then that's a more meaningful issue---because CFLAGS
> doesn't apply there.
Right, this would have failed he
--- Comment #18 from skunk at iskunk dot org 2006-08-07 04:32 ---
(In reply to comment #16)
> > (**None** of what you're saying is currently in the docs, so far as I can
> > see.)
>
> Take a look at http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
Okay, so the sparc64 and CC
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-08-06 11:02
---
> CC+CFLAGS and the --host parameter of configure must always be in keeping.
--build actually.
> For a native compilation (hence a bootstrap), --target must additionally be.
As well as --host.
--
http://g
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-08-06 10:59
---
> (**None** of what you're saying is currently in the docs, so far as I can
> see.)
Take a look at http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
> If users ignoring docs is a problem, then do as t
--- Comment #15 from skunk at iskunk dot org 2006-08-06 09:44 ---
(In reply to comment #13)
> It's worse because tweaking CFLAGS makes you think you can do whatever you
> want with it. You cannot, as explained by Andreas.
Per Andreas, the "cannot" part stems directly from using CC alon
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-08-06 08:48
---
> That's a fairly slippery slope. Does -KPIC/-fPIC/etc. make cc a different
> compiler? -g/-O? -g/-pg? (Yes, the linker might be able to handle those
> combinations, but you may end up with a Frankenbinary that f
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-08-06 08:46
---
> How is it any worse than having those flags in CC? CC and CFLAGS are always
> supposed to be used together anyway---the only difference with what you're
> describing is that this follows the standard variable c
--- Comment #12 from skunk at iskunk dot org 2006-08-06 08:32 ---
(In reply to comment #10)
> Passing -xarch=v9 to the compiler makes it a different compiler in essence,
> one
> that creates object files that are incompatible with the output of the default
> compiler. It also changes t
--- Comment #11 from skunk at iskunk dot org 2006-08-06 08:09 ---
(In reply to comment #9)
> You do for GCC. Tweaking CFLAGS for a bootstrap is a recipe for disaster.
How is it any worse than having those flags in CC? CC and CFLAGS are always
supposed to be used together anyway---the o
--- Comment #10 from schwab at suse dot de 2006-08-06 08:01 ---
(In reply to comment #8)
> You don't pass compiler flags in CC. That's what CFLAGS is for.
Passing -xarch=v9 to the compiler makes it a different compiler in essence, one
that creates object files that are incompatible with
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-08-06 07:34
---
> No, I'm trying to build a 64-bit GCC using cc in 64-bit mode (as per CFLAGS)
> on
> a 64-bit system. Nothing fancy here.
Sure, but you're not using the correct procedure. Use the first I posted.
> You don't
--- Comment #8 from skunk at iskunk dot org 2006-08-06 07:26 ---
(In reply to comment #7)
> You cannot expect that to work. You're trying to bootstrap a 32-bit compiler
> (sparc-sun-solaris2.8) with a 64-bit compiler (cc -xarch=v9). Unsupported.
No, I'm trying to build a 64-bit GCC us
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-08-06 06:43
---
> Configured gcc with CFLAGS=-xarch=v9 (among other flags) to produce 64-bit
> code from the system compiler, instead of the default of 32-bit.
>
> (begin build log excerpt)
> cc -c -g -DENABLE_CHECKING
--- Comment #6 from skunk at iskunk dot org 2006-08-02 16:30 ---
Interestingly enough, the test-cc script teased out an apparent bug in
config/depstand.m4 (routines to check the compiler's mode of dependency
generation). When the compiler is invoked, at the $SHELL line in the below
excer
--- Comment #5 from skunk at iskunk dot org 2006-08-02 16:18 ---
Created an attachment (id=11998)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11998&action=view)
test-cc.pl: Fussy compiler simulator script
This is a Perl script I put together to investigate the CFLAGS behavior,
i
--- Comment #4 from skunk at iskunk dot org 2006-07-28 02:20 ---
(In reply to comment #3)
>
> make STAGE1_CFLAGS=whatever
Yes. Editing the makefile works pretty well too :-)
But the point is, it's a bug for cc(1) to have been invoked without the
original CFLAGS. I admit that I don't f
--- Comment #3 from schwab at suse dot de 2006-07-27 22:19 ---
(In reply to comment #2)
> (In reply to comment #1)
> > You need to also set STAGE1_CFLAGS.
>
> Wait... how does that work?
make STAGE1_CFLAGS=whatever
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
--- Comment #2 from skunk at iskunk dot org 2006-07-27 19:09 ---
(In reply to comment #1)
> You need to also set STAGE1_CFLAGS.
Wait... how does that work?
gcc/Makefile.in has these lines:
# STAGE1_CFLAGS is set by configure on some targets or passed from toplevel
# and sets t
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-27 18:08 ---
You need to also set STAGE1_CFLAGS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
26 matches
Mail list logo
