http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52513
Dave Korn <davek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |WONTFIX
--- Comment #3 from Dave Korn <davek at gcc dot gnu.org> 2012-03-07 13:36:52
UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > 4.6 should be broken as well for you?
> Oops. I reported wrong in my OP. I've actually been using a home-built 4.6.2
> for some time now... and it is the host compiler for this build:
I had no problems building the RC using:
binutils 2.22.51-1
cygwin 1.7.9-1
gcc4 4.5.3-3
gmp 4.3.2-1
make 3.82.90-1
mpfr 3.0.1-1
> > Can you check why configure thinks spawnve is available in process.h
> > (contrary to the warning we see in your snippet)?
> Sorry, I may not have been clear on this. Google reported that spawnve lives
> in
> process.h. A quick search on my filesystem shows that spawnve actually lives
> in
> <cygwin/process.h>, not <process.h> as expected by pex-unix.c.
> Perhaps the file moved recently (since 1.7.9 or 10)? I've sent mail to the
> cygwin list to see if anybody there knows. Meanwhile, soft-linking process.h
> to
> where gcc expects it lets the compile continue.
Right, I think this is a cygwin bug. The /usr/include/cygwin dir is private,
you're not supposed to #include files from there directly, they should be
indirectly included from within other system header files. If process.h is a
public header, it shouldn't have been moved there.
Ah. In fact, I see from the reply to your email there that it is indeed an
acknowledged error in 1.7.10 and fixed already in 1.7.11. Since the .10
release was buggy in several other important ways, I don't think it's important
to support it, we'll just tell people they need to upgrade. Closing as
WONTFIX.
