From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29857 invoked by alias); 7 Mar 2012 13:38:01 -0000 Received: (qmail 29832 invoked by uid 22791); 7 Mar 2012 13:38:00 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Mar 2012 13:37:46 +0000 From: "davek at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/52513] gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin Date: Wed, 07 Mar 2012 13:38:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: davek at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Resolution Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg00627.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52513 Dave Korn changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |RESOLVED Resolution| |WONTFIX --- Comment #3 from Dave Korn 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 > , not 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.