This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch



------- 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 alone (a.k.a. "the
default compiler"), which is the bug at issue.

If tweaking CFLAGS makes me think bad thoughts, then the caveats should be
noted in the build docs, instead of the variable behavior being purposely
broken. (**None** of what you're saying is currently in the docs, so far as I
can see.) If users ignoring docs is a problem, then do as the MPlayer folks do
and have the configure script print a big fat warning if it detects anything
unwholesome.

> You're precisely *not* bootstrapping a compiler on the target system, you're
> building a 32-bit compiler (sparc-sun-solaris2.8) by starting with a 64-bit
> one.  This is a cross-compilation.  You cannot use a bootstrap in that case.
> 
> I guess it's not what you intended, that's why tweaking CFLAGS is dangerous.

So you're saying that CC and the target triplet have to agree, ABI-wise?
Because that would be an issue, in my case---but it's still orthogonal to the
problem of using CC sans CFLAGS. (Here, the resolution would be that I have to
specify the sparc64 triplet explictly, presumably because config.guess returns
the 32-bit triplet irrespective of the system being 64-bit.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]