On 05/07/2009 20:28, Dave Korn wrote: >> * bin/cygport.in: Export CC, CXX, and friends. >> * lib/cmake.cygclass: Use CC, CXX, and LDFLAGS.
These were added, primarily, so that I could easily force gcc4 usage (with -shared-libgcc and -Wl,--enable-auto-import) for _all_ types of build systems. I had hoped that we could make gcc4 the default earlier, but as that was rejected at the time, I maintain a local patch on top of this which does this for now. > 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? > I don't think it's very safe to declare all this stuff in the environment > when there are so many potential things that will behave one way or another > based on a test for either existence or non-emptiness. I think this is > possibly a case of trying to be too helpful. How about deleting the lot, or > only declaring them for cmake builds, or ... any other ideas? The best solution would be to have a stable, preferred-by-alternatives gcc4 with -shared-libgcc on by default, in which case I can stop overriding these. (--enable-auto-import is on by default now with the new binutils-2.19.51 release, right?) Of course, that's exactly what you're trying to do, and I just got in the way. Oops! > 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. Yaakov ------------------------------------------------------------------------------ _______________________________________________ Cygwin-ports-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
