Yaakov (Cygwin/X) wrote:
> On 05/07/2009 20:28, Dave Korn wrote:
>> If you declare CPP or any other such variable in the environment, it
>> overrides any auto-detection that the package's configury might implement.
>> That means that during a GCC bootstrap, it unconditionally uses "cpp" to
>> invoke the preprocessor, when stages 2 and 3 very much want to use the
>> previous stage's xgcc driver (along with assorted -nostdinc, -B, -isystem,
>> and
>> -E flags), and even stage 1 really needs to use "$(CC) -E".
>
> Sounds like a bug in gcc machinery to me; if boostrapping, the supplied
> CC,CPP,... should only be accepted for stage1. Does this affect CC as
> well during stages 2/3, or just CPP?
Just CPP, as far as I noticed. It could well be a bug.
> (--enable-auto-import is on by default now with the
> new binutils-2.19.51 release, right?)
Yep :)
>> I can unset all these vars in my project's .cygport,
>
> Probably not a bad idea in any case, given the nature of the gcc build;
> you never know what someone might have set in their environment.
>
>> but isn't doing this liable to have unexpected effects all over the place?
>
> Actually it's been quite helpful, but then again, I'm not building gcc.
>
> Please let me know how I can help.
Hmm. I think a problem is that there's no way you can make your default
setting be "${CC} -E" and have it get automatically recalculated / deferred
evaluation in the even that something subsequently recalculates CC, is there?
I'm not sure I can see anything useful to do about it. Maybe just omit the
CPP (and CXXCPP) definitions, on the ground that they will always be inferred
from "$(CC) -E" anyway? And perhaps you should omit CPPFLAGS and LIBS as
well; what benefit can there be in supplying an empty default?
cheers,
DaveK
------------------------------------------------------------------------------
_______________________________________________
Cygwin-ports-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
