Ouch. This one just bit me bigtime. Spent the whole day wondering why
gcc-4.3.3-1 kept failing to build stage3 in libstdc++, which turned out to be
an autoconf test spuriously defining HAVE_FENV_H, which in turn turned out to
be because it wasn't passing the -nostdinc++ flag down on the command line
when preprocessing, which in turn turned out to be because ... well, after a
lot of debugging and wondering why it was configuring differently from a clean
build, it turns out to be because of a recent change in cygport.
> Revision 6684 - (view) (download) (annotate) - [select for diffs]
> Modified Fri Jun 5 01:28:24 2009 UTC (4 weeks, 2 days ago) by yselkowitz
> File length: 49059 byte(s)
> Diff to previous 6682
>
> * bin/cygport.in: Export CC, CXX, and friends.
> * lib/cmake.cygclass: Use CC, CXX, and LDFLAGS.
It was the new variable CPP in particular:
> # Values which can be overridden either system-wide or per package
> +declare -x CC="gcc";
> declare -x CFLAGS="-O2 -pipe ";
> +declare -x CPP="cpp";
> declare -x CPPFLAGS="";
> +declare -x CXX="g++";
> +declare -x CXXCPP="cpp";
> declare -x CXXFLAGS="${CFLAGS}";
> +declare -x F77="g77";
> declare -x FFLAGS="${CFLAGS}";
> +declare -x GCJ="gcj";
> declare -x GCJFLAGS="${CFLAGS}";
> declare -x LDFLAGS="-Wl,--enable-auto-import ";
> declare -x LIBS="";
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".
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? I can unset all
these vars in my project's .cygport, but isn't doing this liable to have
unexpected effects all over the place?
cheers,
DaveK
------------------------------------------------------------------------------
_______________________________________________
Cygwin-ports-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
