Re: GCC 4.6.0 Released
> Dennis Clarke writes: > >>> The only caveat are strange errors with gmake: >>> >>> make[3]: write error >>> >>> See CR 6938116 GNU make highly unreliable: `write error' message. >>> >>> I've hacked around this by ignoring the error in misc.c (close_stdout) >>> ;-) >>> >> >> It seems odd that gmake would pass every test in its own testsuite and >> then get an odd little message like that. Oh well, if you feel it can be > > It only happens once in a while, and primarily for Solaris 11 NFS > servers. Even more rarely, it occurs on Solaris 11 locally. I generally build my prod things on Solaris 8 with the assumption that the Solaris ABI stability will provide what I need up to Solaris 9. Then I rebuild again on Solaris 10 for AMD64/x86_64 functionality. This has worked well thus far. I avoid Solaris 11 Express entirely as I just don't see it as a valid release yet. If the OpenSolaris project was still alive and the bug process was open then I'd may feel differently but with thing being as they are ... I avoid Sol 11 for now. > >> ignored then I'm so very happy to see this. > > I think it is harmless enough to be ignored in this particular case, but > this deviation from pre-S11 behaviour is bad. Suddenly expecting every > single piece of software to handle EINTR all over the place when you > didn't need to before and don't need it on any other platform isn't > exactly a winning proposition to me ;-( I'll try to pursue this with > Solaris engineering. How is that going ? I have filed bugs in the past regarding Studio 11 Update 1 and was not exactly thrilled with the response. However .. dropping an email to Daryl Gove can generally get things moving. >> By the way, I just want to say thank you for posting results on Solaris >> because I review them and use them for comparison all the time. I am >> still >> fascinated that GCC can post different results on two servers running >> the >> same OS and probably with the same revs of tools avail. >> >> Consider this on Sol 8 i386 : >> >> === gcc Summary === >> >> # of expected passes72652 >> # of unexpected failures18 >> # of expected failures 212 >> # of unresolved testcases 1 >> # of unsupported tests 1874 >> /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc version 4.6.0 >> (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011) >> >> This : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02832.html >> >> === gcc Summary === >> >> # of expected passes 74529 >> # of unexpected failures 1 >> # of expected failures 212 >> # of unresolved testcases1 >> # of unsupported tests 1031 >> /var/gcc/gcc-4.6.0/8-gcc-gas/gcc/xgcc version 4.6.0 (GCC) > > One would have to compare gcc.sum in detail to know what's going on. > Well my testsuite run with N=2 finished and the results look like : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg03106.html === gcc Summary === # of expected passes72652 # of unexpected failures18 # of expected failures 212 # of unresolved testcases 1 # of unsupported tests 1874 /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc version 4.6.0 (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011) Exact same as before ! This is a very good sign. OKay .. so my days of running gmake -k check as a single thread are over. Thank you very much! >> I decided to toss caution to the wind and run my build with as and ld in >> /usr/ccs/bin and I was happy to see a decent result set. I often wonder >> if >> we *need* GNU as or just *want* GNU as in an older Solaris release like >> 8. > > IMO you want gas on Solaris/x86 before 10 because as lacks several > features there (like visibility support). On Solaris 10/x86 and up, as > is mostly fine (primarily COMDAT group support is missing, but I'm > working on that with the assembler and linker engineers as we speak). > Unfortunately, a recent as patch broke several -gstabs tests, but this > is expected to be fixed soon. > > On Solaris/SPARC I usually do the production builds with as; there seems > little reason to go for gas instead. > > Hope this helps. Very much so, thank you. I'll go back and rebuild on x86 with gas and leave my Sparc build as is. I generally do a double bootstrap merely to see what happens when GCC 4.6.0 is built with GCC 4.6.0 after it has already been bootstrapped. If I see any significant changes in the testsuite results then I assume something funky is afoot. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.6.0 Released
Dennis Clarke writes: >> The only caveat are strange errors with gmake: >> >> make[3]: write error >> >> See CR 6938116 GNU make highly unreliable: `write error' message. >> >> I've hacked around this by ignoring the error in misc.c (close_stdout) ;-) >> > > It seems odd that gmake would pass every test in its own testsuite and > then get an odd little message like that. Oh well, if you feel it can be It only happens once in a while, and primarily for Solaris 11 NFS servers. Even more rarely, it occurs on Solaris 11 locally. > ignored then I'm so very happy to see this. I think it is harmless enough to be ignored in this particular case, but this deviation from pre-S11 behaviour is bad. Suddenly expecting every single piece of software to handle EINTR all over the place when you didn't need to before and don't need it on any other platform isn't exactly a winning proposition to me ;-( I'll try to pursue this with Solaris engineering. > By the way, I just want to say thank you for posting results on Solaris > because I review them and use them for comparison all the time. I am still > fascinated that GCC can post different results on two servers running the > same OS and probably with the same revs of tools avail. > > Consider this on Sol 8 i386 : > > === gcc Summary === > > # of expected passes72652 > # of unexpected failures18 > # of expected failures 212 > # of unresolved testcases 1 > # of unsupported tests 1874 > /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc version 4.6.0 > (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011) > > This : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02832.html > > === gcc Summary === > > # of expected passes 74529 > # of unexpected failures 1 > # of expected failures212 > # of unresolved testcases 1 > # of unsupported tests1031 > /var/gcc/gcc-4.6.0/8-gcc-gas/gcc/xgcc version 4.6.0 (GCC) One would have to compare gcc.sum in detail to know what's going on. > I decided to toss caution to the wind and run my build with as and ld in > /usr/ccs/bin and I was happy to see a decent result set. I often wonder if > we *need* GNU as or just *want* GNU as in an older Solaris release like 8. IMO you want gas on Solaris/x86 before 10 because as lacks several features there (like visibility support). On Solaris 10/x86 and up, as is mostly fine (primarily COMDAT group support is missing, but I'm working on that with the assembler and linker engineers as we speak). Unfortunately, a recent as patch broke several -gstabs tests, but this is expected to be fixed soon. On Solaris/SPARC I usually do the production builds with as; there seems little reason to go for gas instead. Hope this helps. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: GCC 4.6.0 Released
> Dennis Clarke writes: > >> Do you know if anyone has ever tested that on Solaris ? Lately Solaris >> is >> where open source goes to die ( blame Larry for that ) so I figure I may >> as well give it a shot, but before I do .. tell me know if this little >> trick works at all. > > Why shouldn't it? No idea, and in the absence of data, I just am not sure yet. > I'm using it all the way from Solaris 8 to 11, with N > from 2 on a single-CPU HP Proliant DL-320 G2 via 96 on a 8-socket > NehalemEX Fujitsu RX900 S1 up to 128 on a SPARC Enterprise T5120. > awesome ... I am running it right now with N=2 and I have to assume that it will do the *exact* same results for my testsuite results. I already posted this : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02960.html So right now the very same machine, with no changes at all, is runnung with N=2. Thus far it looks to be quite busy : mpstat 5 says . . . CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 4552 1 151 623 235 399 100 80 820 4185 50 46 4 0 1 4538 1 225 286 49 360 106 76 810 3200 59 38 2 1 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 3836 1 213 582 282 316 93 62 620 3375 62 34 3 0 1 4463 0 142 378 81 348 108 57 640 3655 62 36 2 1 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 3180 1 141 521 220 286 81 56 440 3363 65 32 2 1 1 2895 0 150 258 38 298 93 59 490 2791 67 30 2 0 . . . > The only caveat are strange errors with gmake: > > make[3]: write error > > See CR 6938116GNU make highly unreliable: `write error' message. > > I've hacked around this by ignoring the error in misc.c (close_stdout) ;-) > It seems odd that gmake would pass every test in its own testsuite and then get an odd little message like that. Oh well, if you feel it can be ignored then I'm so very happy to see this. By the way, I just want to say thank you for posting results on Solaris because I review them and use them for comparison all the time. I am still fascinated that GCC can post different results on two servers running the same OS and probably with the same revs of tools avail. Consider this on Sol 8 i386 : === gcc Summary === # of expected passes72652 # of unexpected failures18 # of expected failures 212 # of unresolved testcases 1 # of unsupported tests 1874 /opt/bw/src/GCC/gcc-4.6.0_SunOS5.8_i386.001/gcc/xgcc version 4.6.0 (Blastwave.org Inc. Mon Mar 28 13:18:17 GMT 2011) This : http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02832.html === gcc Summary === # of expected passes74529 # of unexpected failures1 # of expected failures 212 # of unresolved testcases 1 # of unsupported tests 1031 /var/gcc/gcc-4.6.0/8-gcc-gas/gcc/xgcc version 4.6.0 (GCC) I decided to toss caution to the wind and run my build with as and ld in /usr/ccs/bin and I was happy to see a decent result set. I often wonder if we *need* GNU as or just *want* GNU as in an older Solaris release like 8. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.6.0 Released
Dennis Clarke writes: > Do you know if anyone has ever tested that on Solaris ? Lately Solaris is > where open source goes to die ( blame Larry for that ) so I figure I may > as well give it a shot, but before I do .. tell me know if this little > trick works at all. Why shouldn't it? I'm using it all the way from Solaris 8 to 11, with N from 2 on a single-CPU HP Proliant DL-320 G2 via 96 on a 8-socket NehalemEX Fujitsu RX900 S1 up to 128 on a SPARC Enterprise T5120. The only caveat are strange errors with gmake: make[3]: write error See CR 6938116 GNU make highly unreliable: `write error' message. I've hacked around this by ignoring the error in misc.c (close_stdout) ;-) Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: GCC 4.6.0 Released
> On Wed, Mar 30, 2011 at 11:45:38PM -0700, Ian Lance Taylor wrote: >> Ryan Hill writes: >> >> > Does anyone know since when (if) running make check with more than one >> job >> > has been supported? IIRC back in the 3.x days it caused issues so >> we've >> > been forcing -j1 here forever. If we could run it in parallel that >> would be a >> > big timesaver. >> >> Jakub fixed it back in 2008 for gcc 4.4. It is indeed a big timesaver. > > Fixed just in the sense that the testing is more parallelized. > I've been using make -jN -k check for more than a decade and I don't > remember problems with that, mudflap tests are flaky and tend to fail > more often under load, but mudflap has only been added in 4.0. > Of course the N keeps changing over time, but currently testing certainly > works with -j48 that I'm using daily. > > Jakub Do you know if anyone has ever tested that on Solaris ? Lately Solaris is where open source goes to die ( blame Larry for that ) so I figure I may as well give it a shot, but before I do .. tell me know if this little trick works at all. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris
Re: GCC 4.6.0 Released
On Wed, Mar 30, 2011 at 11:45:38PM -0700, Ian Lance Taylor wrote: > Ryan Hill writes: > > > Does anyone know since when (if) running make check with more than one job > > has been supported? IIRC back in the 3.x days it caused issues so we've > > been forcing -j1 here forever. If we could run it in parallel that would > > be a > > big timesaver. > > Jakub fixed it back in 2008 for gcc 4.4. It is indeed a big timesaver. Fixed just in the sense that the testing is more parallelized. I've been using make -jN -k check for more than a decade and I don't remember problems with that, mudflap tests are flaky and tend to fail more often under load, but mudflap has only been added in 4.0. Of course the N keeps changing over time, but currently testing certainly works with -j48 that I'm using daily. Jakub
Re: GCC 4.6.0 Released
Ryan Hill writes: > Does anyone know since when (if) running make check with more than one job > has been supported? IIRC back in the 3.x days it caused issues so we've > been forcing -j1 here forever. If we could run it in parallel that would be a > big timesaver. Jakub fixed it back in 2008 for gcc 4.4. It is indeed a big timesaver. Ian
Re: GCC 4.6.0 Released
On Tue, 29 Mar 2011 12:29:13 -0400 NightStrike wrote: > On Tue, Mar 29, 2011 at 10:45 AM, Dave Korn > wrote: > > True but takes rather a long time on a cygwin host that's already running > > "make -j8 check"! So I asked. Apologies for minor laziness, hope you > > didn't > > feel /obligated/ to respond. > > [Slightly off-topic] > > How did you manage to run make check on cygwin with -j8 without > getting tons of spurious errors about all kinds of weird things? I > can't run anything over -j1 on a 4 core machine. [more off-topic] Does anyone know since when (if) running make check with more than one job has been supported? IIRC back in the 3.x days it caused issues so we've been forcing -j1 here forever. If we could run it in parallel that would be a big timesaver. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: GCC 4.6.0 Released
On 03/30/2011 09:10 AM, Bernd Roesch wrote: > I add an error in file libiberty/pex-win32.c to check if cygwin build use > win32_spawn. That's because it doesn't use pex-win32.c. > I add now an error in pex_unix.c, and compile file.so cygwin build use vfork > stuff. You need to look more carefully. Search for HAVE_SPAWNVPE. r~
Re: GCC 4.6.0 Released
Bernd Roesch writes: > I add an error in file libiberty/pex-win32.c to check if cygwin build use > win32_spawn. > but gcc compile ok, so it seem that cygwin build do not use pex-win32.c.Or > need i set a compile > option for GCC ? The choice is determined in libiberty/configure.ac: *-*-mingw* | *-*-winnt*) pexecute=pex-win32 ;; *-*-msdosdjgpp*) pexecute=pex-djgpp ;; *-*-msdos*)pexecute=pex-msdos ;; *) pexecute=pex-unix ;; It may be appropriate to use pex-win32 for *-*-cygwin*. I don't know, as I am not a cygwin user myself. Ian
Re: GCC 4.6.0 Released
Hello On 29.03.11, you wrote: >> >> This sounds like the generic Cygwin fork-error/BLODA problem and not >> specific to GCC. > > Indeed. For what it's worth, gcc itself *does* use the Cygwin spawn* > functions > to avoid this problem, but (curiously) the Cygwin versions of make, bash, and > expect do not. Therefore the problem can still be seen during a build. I add an error in file libiberty/pex-win32.c to check if cygwin build use win32_spawn. but gcc compile ok, so it seem that cygwin build do not use pex-win32.c.Or need i set a compile option for GCC ? static pi d_t win32_spawn (const char *executable, I add now an error in pex_unix.c, and compile file.so cygwin build use vfork stuff. static pid_t pex_unix_exec_child (struct pex_obj *obj, int flags, const char *executable, I try to build a gprof build, but i dont know what options i need set for GCC build and if gprof work on cygwin. this is in config.log $ /bernd/gcc4/configure --target=m68k-amigaos --with-cpu=m68040 --prefix=/usr/local/amiga ... configure:2429: checking build system type configure:2443: result: i686-pc-cygwin configure:2490: checking host system type configure:2503: result: i686-pc-cygwin configure:2523: checking target system type configure:2536: result: m68k-unknown-amigaos configure:2590: checking for a BSD-compatible install configure:2658: result: /usr/bin/install -c > > > r~ Regards
Re: GCC 4.6.0 Released
On 03/29/2011 05:53 AM, Dave Korn wrote: >> I think it can too in readme add that on current cygwin on win 64 and >> multicore CPU GCC compile lots slower as on single CPU systems. To speed up >> GCC and compile 3* faster in windows taskmanager can the CPU number set to >> 1 for the shell task. >> >> But i hope there come some day a fix for this problem.I get sometimes hang >> and after 10-20 sec come a message that vfork problem is detect. maybe when >> GCC use fork for task create or native windows task create it work better ? > > This sounds like the generic Cygwin fork-error/BLODA problem and not > specific to GCC. Indeed. For what it's worth, gcc itself *does* use the Cygwin spawn* functions to avoid this problem, but (curiously) the Cygwin versions of make, bash, and expect do not. Therefore the problem can still be seen during a build. r~
Re: GCC 4.6.0 Released
On Tue, Mar 29, 2011 at 10:45 AM, Dave Korn wrote: > On 29/03/2011 15:32, Jakub Jelinek wrote: >> On Tue, Mar 29, 2011 at 03:13:07PM +0100, Dave Korn wrote: >>> On 28/03/2011 08:25, Jakub Jelinek wrote: The GNU Compiler Collection version 4.6.0 has been released. >>> Were there any changes (other than perhaps repackaging) after the second >>> RC >>> (dated 20110321)? >> >> You can easily look at svn. > > True but takes rather a long time on a cygwin host that's already running > "make -j8 check"! So I asked. Apologies for minor laziness, hope you didn't > feel /obligated/ to respond. [Slightly off-topic] How did you manage to run make check on cygwin with -j8 without getting tons of spurious errors about all kinds of weird things? I can't run anything over -j1 on a 4 core machine.
Re: GCC 4.6.0 Released
On 29/03/2011 15:32, Jakub Jelinek wrote: > On Tue, Mar 29, 2011 at 03:13:07PM +0100, Dave Korn wrote: >> On 28/03/2011 08:25, Jakub Jelinek wrote: >>> The GNU Compiler Collection version 4.6.0 has been released. >> Were there any changes (other than perhaps repackaging) after the second RC >> (dated 20110321)? > > You can easily look at svn. True but takes rather a long time on a cygwin host that's already running "make -j8 check"! So I asked. Apologies for minor laziness, hope you didn't feel /obligated/ to respond. > But if you want a summary, gcc.pot/cpplib.pot > have been regenerated, _ZNSsC2EOSs and _ZNSbIwSt11char_traitsIwESaIwEEC2EOS2_ > are newly exported from libstdc++.so.6, _ZTS[PK]*[no] are no longer > exported and _ZTI[PK]*[no] is exported under correct symbol version, > lots of libstdc++ baseline_symbols.txt updates for various targets > and the usual release changes (ChangeLog updates, DEV-PHASE change) > and DATESTAMP updates. Thanks for the summary. The export changes in particular may be relevant to me. cheers, DaveK
Re: GCC 4.6.0 Released
On Tue, Mar 29, 2011 at 03:13:07PM +0100, Dave Korn wrote: > On 28/03/2011 08:25, Jakub Jelinek wrote: > > The GNU Compiler Collection version 4.6.0 has been released. > > Were there any changes (other than perhaps repackaging) after the second RC > (dated 20110321)? You can easily look at svn. But if you want a summary, gcc.pot/cpplib.pot have been regenerated, _ZNSsC2EOSs and _ZNSbIwSt11char_traitsIwESaIwEEC2EOS2_ are newly exported from libstdc++.so.6, _ZTS[PK]*[no] are no longer exported and _ZTI[PK]*[no] is exported under correct symbol version, lots of libstdc++ baseline_symbols.txt updates for various targets and the usual release changes (ChangeLog updates, DEV-PHASE change) and DATESTAMP updates. Jakub
Re: GCC 4.6.0 Released
On 28/03/2011 08:25, Jakub Jelinek wrote: > The GNU Compiler Collection version 4.6.0 has been released. Were there any changes (other than perhaps repackaging) after the second RC (dated 20110321)? cheers, DaveK
Re: GCC 4.6.0 Released
On 29/03/2011 09:50, Bernd Roesch wrote: > Hello > > On 28.03.11, you wrote: > >> I think that the right place for the note is at >> >> http://gcc.gnu.org/install/specific.html#x-x-cygwin >> >> It should say something like: >> >> Versions of Cygwin older than x.y.z fail to build the decimal floating >> point library, libbid. You will either need to upgrade Cygwin to a newer >> version or disable decimal floating point by specifying >> --disable-decimal-float at configure time. > > I think it can too in readme add that on current cygwin on win 64 and > multicore CPU GCC compile lots slower as on single CPU systems. To speed up > GCC and compile 3* faster in windows taskmanager can the CPU number set to > 1 for the shell task. > > But i hope there come some day a fix for this problem.I get sometimes hang > and after 10-20 sec come a message that vfork problem is detect. maybe when > GCC use fork for task create or native windows task create it work better ? This sounds like the generic Cygwin fork-error/BLODA problem and not specific to GCC. cheers, DaveK
Re: GCC 4.6.0 Released
On 28/03/2011 19:52, FX wrote: >> this is a known issue and strictly cygwin related. Please update your >> cygwin environment to newest version, or disable decimal-floating >> point by option. > > Well, maybe this is known, but it is not noted on the GCC 4.6.0 release > notes, nor on the target-specific installation information page at > http://gcc.gnu.org/install/specific.html#x-x-cygwin > Possibly one of the target maintainers might want to update that? Yes indeed I should, I will get on with that pronto. cheers, DaveK
Re: GCC 4.6.0 Released
Hello On 28.03.11, you wrote: > > I think that the right place for the note is at > > http://gcc.gnu.org/install/specific.html#x-x-cygwin > > It should say something like: > > Versions of Cygwin older than x.y.z fail to build the decimal floating > point library, libbid. You will either need to upgrade Cygwin to a newer > version or disable decimal floating point by specifying > --disable-decimal-float > at configure time. I think it can too in readme add that on current cygwin on win 64 and multicore CPU GCC compile lots slower as on single CPU systems. To speed up GCC and compile 3* faster in windows taskmanager can the CPU number set to 1 for the shell task. But i hope there come some day a fix for this problem.I get sometimes hang and after 10-20 sec come a message that vfork problem is detect. maybe when GCC use fork for task create or native windows task create it work better ? > > Regards
Re: GCC 4.6.0 Released
On Mon, Mar 28, 2011 at 11:52:56AM -0700, FX wrote: > > this is a known issue and strictly cygwin related. Please update your > > cygwin environment to newest version, or disable decimal-floating > > point by option. > > Well, maybe this is known, but it is not noted on the GCC 4.6.0 release > notes, nor on the target-specific installation information page at > http://gcc.gnu.org/install/specific.html#x-x-cygwin > Possibly one of the target maintainers might want to update that? I think that the right place for the note is at http://gcc.gnu.org/install/specific.html#x-x-cygwin It should say something like: Versions of Cygwin older than x.y.z fail to build the decimal floating point library, libbid. You will either need to upgrade Cygwin to a newer version or disable decimal floating point by specifying --disable-decimal-float at configure time.
Re: GCC 4.6.0 Released
> this is a known issue and strictly cygwin related. Please update your > cygwin environment to newest version, or disable decimal-floating > point by option. Well, maybe this is known, but it is not noted on the GCC 4.6.0 release notes, nor on the target-specific installation information page at http://gcc.gnu.org/install/specific.html#x-x-cygwin Possibly one of the target maintainers might want to update that? FX
Re: GCC 4.6.0 Released
2011/3/28 Piotr Wyderski : > Jakub Jelinek : > >> The GNU Compiler Collection version 4.6.0 has been released. > > Compilation failure on Cygwin: > > ../../../libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: > fenv.h: > No such file or directory > compilation terminated. > make[3]: *** [bid_decimal_globals.o] Error 1 > > Configured as: > > ../configure --prefix=/opt/gcc-4.6.0 -v --enable-bootstrap > --enable-version-specific-runtime-libs --enable-static > --enable-shared --enable-shared-libgcc --disable-__cxa_atexit > --with-gnu-ld --with-gnu-as --with-dwarf2 > --disable-sjlj-exceptions --enable-languages=c,c++ --disable-symvers > --enable-libgomp --enable-libssp > --enable-threads=posix --with-arch=core2 --with-tune=generic > --enable-libgcj-sublibs > > Best regards > Piotr Wyderski Piotr, this is a known issue and strictly cygwin related. Please update your cygwin environment to newest version, or disable decimal-floating point by option. Regards, Kai
Re: GCC 4.6.0 Released
Jakub Jelinek : > The GNU Compiler Collection version 4.6.0 has been released. Compilation failure on Cygwin: ../../../libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory compilation terminated. make[3]: *** [bid_decimal_globals.o] Error 1 Configured as: ../configure --prefix=/opt/gcc-4.6.0 -v --enable-bootstrap --enable-version-specific-runtime-libs --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=c,c++ --disable-symvers --enable-libgomp --enable-libssp --enable-threads=posix --with-arch=core2 --with-tune=generic --enable-libgcj-sublibs Best regards Piotr Wyderski
