[Bug bootstrap/52513] gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin
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.
[Bug bootstrap/52513] gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52513 --- Comment #2 from Ryan Johnson 2012-03-07 13:02:50 UTC --- (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: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/Ryan/apps/gcc-4.6.2/libexec/gcc/i686-pc-cygwin/4.6.2/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ../gcc-4.6.2-src/configure --prefix=/home/Ryan/apps/gcc-4.6.2 Thread model: single gcc version 4.6.2 (GCC) > > 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. Configure probably only tested linker status for the function and therefore wouldn't have noticed. 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. I'll report back if any further issues arise. > What Windows version are you using? W7-x64
[Bug bootstrap/52513] gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52513 Richard Guenther changed: What|Removed |Added Target||i686-pc-cygwin Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-07 CC||davek at gcc dot gnu.org, ||rguenth at gcc dot gnu.org, ||rth at gcc dot gnu.org Host||i686-pc-cygwin Ever Confirmed|0 |1 Build||i686-pc-cygwin --- Comment #1 from Richard Guenther 2012-03-07 09:44:34 UTC --- Probably caused by 2010-11-04 Richard Henderson * configure.ac (AC_CHECK_HEADERS): Add process.h. (checkfuncs): Add dup3, spawnve, spawnvpe; sort the list. (AC_CHECK_FUNCS): Add dup3, spawnve, spawnvpe. * configure, config.in: Rebuild. * pex-unix.c [HAVE_SPAWNVE] (pex_unix_exec_child): New function. [HAVE_SPAWNVE] (save_and_install_fd, restore_fd): New functions. thus 4.6 should be broken as well for you? Can you check why configure thinks spawnve is available in process.h (contrary to the warning we see in your snippet)? What Windows version are you using?
