public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "davek at gcc dot gnu.org" <gcc-bugzilla@gcc.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	[thread overview]
Message-ID: <bug-52513-4-4JKVMgU4yW@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-52513-4@http.gcc.gnu.org/bugzilla/>

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.


      parent reply	other threads:[~2012-03-07 13:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-06 20:38 [Bug bootstrap/52513] New: " scovich at gmail dot com
2012-03-07  9:45 ` [Bug bootstrap/52513] " rguenth at gcc dot gnu.org
2012-03-07 13:03 ` scovich at gmail dot com
2012-03-07 13:38 ` davek at gcc dot gnu.org [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-52513-4-4JKVMgU4yW@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).