Re: GCC 4.x for cygwin
Roberto Bagnara wrote: > > Where can I find it? (From the installer it seems that > the latest available version is 3.4.4, but this is really > unusable for serious C++ development.) There's too much on this subject in the archives to be summarized. Why not look yourself? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc 4.x?
My apologies, I must have missed the latest one about GCC 4.2.0 RC3 for some reason, sorry. Tom wrote: There is an email thread from 2006 to this topic: http://cygwin.com/ml/cygwin/2006-03/msg00507.html I have compiled my own GCC 4.2.0 for cygwin, but not tested and not really used it a lot. And I must admit that what Charles et al were talking about is not my core expertise. I would appreciate any status update on 4.x, too. Brian Hassink wrote: > Just curious what the issues are that are holding up [..] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc 4.x?
There is an email thread from 2006 to this topic: http://cygwin.com/ml/cygwin/2006-03/msg00507.html I have compiled my own GCC 4.2.0 for cygwin, but not tested and not really used it a lot. And I must admit that what Charles et al were talking about is not my core expertise. I would appreciate any status update on 4.x, too. Brian Hassink wrote: > Just curious what the issues are that are holding up [..] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
On Fri, Mar 17, 2006 at 10:55:53PM -0800, Tim Prince wrote: >I've heard of some reluctance among gcc developers to continue support >for cygwin. There seems to be a lack of interest in problem solving, or >in overcoming the binutils bottleneck in the way of a 64-bit native >cygwin. Huh? Could you point me at a developer who is expressing reluctance? I know most of them and hang out on the gcc irc channel and no one has said anything to me. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Charles Wilson wrote: Brian Dessent wrote: Angelo Graziosi wrote: I have built GCC-3.4.6, 4.0.3, 4.1.0 in this way (using the Cygwin GCC-3.4.4-1): ./configure --prefix=/usr/local/gcc-3.4.6 (or 4.0.3, 4.1.0) make make install I like to use --enable-version-specific-runtime-libs because it seems cleaner and that's the way the Cygwin gcc packages do it. I also use --disable-nls since I don't care for those dozens of various message catalog files for languages I don't speak. You will also need --enable-sjlj-exceptions if you ever plan to compile code that could throw an exception inside a stack frame containing foreign (non-DW2-enabled) compiled code, such as a win32 callback. This can be common in win32 GUI applications, but not an issue if you don't use C++ exceptions and/or you don't write code that could be called from a win32 callback. The dwarf2 EH is a lot faster too. I thought there were some patches to the cygwin gcc 3.4.x version that had not yet been migrated to the official sources? I'd be glad to be wrong, however. Also, wasn't there some issue with the std::string implementation that was causing problems for both cygwin-special and mingw-special g++? Otherwise, if it's so simple, I don't understand why Gerrit hasn't released gcc-4.x as a test version, nor [OT:] why Danny hasn't released a gcc-4.0 candidate for mingw. We don't appear to have a full concensus even on the build options, although copying some of the options which appear in cygwin special gcc might be a start. Also, as pointed out above, building standard gcc "out of the box" doesn't enable all of the features required of cygwin. At least a few of those versions mentioned above include the option to build treelang, enabling the option -ftree-vectorize. For me, this passes all of gcc-testsuite, but still exhibits some serious problems which I can't reproduce in linux. I haven't succeeded in building libstdc++ for gcc-4.1 or 4.2. Maybe the discussion above implies a few others have seen the same problem. That would be enough to explain to me why such a version hasn't appeared in cygwin, even if it's a relatively simple patch (maybe even trivially obvious to someone). I've heard of some reluctance among gcc developers to continue support for cygwin. There seems to be a lack of interest in problem solving, or in overcoming the binutils bottleneck in the way of a 64-bit native cygwin. I see some effort toward making gcc-4.2 gomp work for cygwin, thus some counter to the pessimism I just expressed. No doubt, the reported 4% market penetration of 64-bit Windows may be dissuading some from thinking Windows has much prospect for near term progress. When Microsoft cc'd me an e-mail suggesting a $30,000 budget for each customer to find out how to run CCS, my own doubts were hardly put to rest. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Charles Wilson wrote: > I thought there were some patches to the cygwin gcc 3.4.x version that > had not yet been migrated to the official sources? I'd be glad to be > wrong, however. There's the patch that fixes throwing exceptions across DLLs (or something like that.) I know it's been submitted by Danny but I think it withered and he wasn't interested in championing it. The thing is, 4.x is so vastly different than 3.x that I'm not sure if it's still even needed or not. > Also, wasn't there some issue with the std::string implementation that > was causing problems for both cygwin-special and mingw-special g++? Yes, this can be fixed (with a somewhat severe performance penalty) by configuring libstdc++ with --enable-fully-dynamic-string. There's a patch against 3.4 that fixes this in a less invasive way, but no equivalent for 4.x AFAIK. On this issue though even the current 3.4 gcc packages are broken, so it wouldn't be a regression per se. > Otherwise, if it's so simple, I don't understand why Gerrit hasn't > released gcc-4.x as a test version, nor [OT:] why Danny hasn't released > a gcc-4.0 candidate for mingw. Well, I know there still some rough edges with 4.x and cygwin/mingw, which might prevent the maintainers from deploying it just on the basis that a somewhat-broken compiler is worse than no compiler. The last time I tried a cygwin1.dll compiled with gcc 4.x it was nowhere close to being functional, presumably because the stricter enforcement of aliasing rules or more aggressive optimizations uncovered code problems. But the person that started the thread just wanted to try GCC on his own code, which sounded to me like the appropriate thing is just build it and find out, since it's trivial to keep a number of independant installed versions of gcc. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Brian Dessent wrote: Angelo Graziosi wrote: I have built GCC-3.4.6, 4.0.3, 4.1.0 in this way (using the Cygwin GCC-3.4.4-1): ./configure --prefix=/usr/local/gcc-3.4.6 (or 4.0.3, 4.1.0) make make install I like to use --enable-version-specific-runtime-libs because it seems cleaner and that's the way the Cygwin gcc packages do it. I also use --disable-nls since I don't care for those dozens of various message catalog files for languages I don't speak. You will also need --enable-sjlj-exceptions if you ever plan to compile code that could throw an exception inside a stack frame containing foreign (non-DW2-enabled) compiled code, such as a win32 callback. This can be common in win32 GUI applications, but not an issue if you don't use C++ exceptions and/or you don't write code that could be called from a win32 callback. The dwarf2 EH is a lot faster too. I thought there were some patches to the cygwin gcc 3.4.x version that had not yet been migrated to the official sources? I'd be glad to be wrong, however. Also, wasn't there some issue with the std::string implementation that was causing problems for both cygwin-special and mingw-special g++? Otherwise, if it's so simple, I don't understand why Gerrit hasn't released gcc-4.x as a test version, nor [OT:] why Danny hasn't released a gcc-4.0 candidate for mingw. Other than "we're just mean". :-) I mean, hey, they're volunteers and far be it from me to criticize, given my lackluster record as a maintainer of late...but somehow I doubt that it's really as easy as you claim -- otherwise those two guys woulda done it by now. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Angelo Graziosi wrote: > > The dwarf2 EH is a lot faster too > > Does this mean to use: --with-dwarf2 option in 'configure'? No, that's setting the default debug symbol type to dwarf2 instead of stabs (I think). You get dwarf2 exception handling by default without having to specify anything unless you override with --enable-sjlj-exceptions. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Brian Dessent wrote: > The dwarf2 EH is a lot faster too Does this mean to use: --with-dwarf2 option in 'configure'? Thanks a lot, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Angelo Graziosi wrote: > I have built GCC-3.4.6, 4.0.3, 4.1.0 in this way (using the Cygwin > GCC-3.4.4-1): > >./configure --prefix=/usr/local/gcc-3.4.6 (or 4.0.3, 4.1.0) >make >make install I like to use --enable-version-specific-runtime-libs because it seems cleaner and that's the way the Cygwin gcc packages do it. I also use --disable-nls since I don't care for those dozens of various message catalog files for languages I don't speak. You will also need --enable-sjlj-exceptions if you ever plan to compile code that could throw an exception inside a stack frame containing foreign (non-DW2-enabled) compiled code, such as a win32 callback. This can be common in win32 GUI applications, but not an issue if you don't use C++ exceptions and/or you don't write code that could be called from a win32 callback. The dwarf2 EH is a lot faster too. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Brian Dessent wrote: > If you pick a proper --prefix (or use --program-suffix and > --enable-version-specific-runtime-libs) it will be completely separate > from the installed version of gcc, you can use the two side by side. I have built GCC-3.4.6, 4.0.3, 4.1.0 in this way (using the Cygwin GCC-3.4.4-1): ./configure --prefix=/usr/local/gcc-3.4.6 (or 4.0.3, 4.1.0) make make install May you suggest other optimal options for 'configure' ? Thanks, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GCC 4.x+
Václav Haisman wrote: > is there a plan to move Cygwin over to newer GCC? GCC 3.4.4 is getting > old. I could use the strictness of C++ compiler it brings. There's no reason why you can't build gcc 4.x on your own, it works fine in Cygwin. If you pick a proper --prefix (or use --program-suffix and --enable-version-specific-runtime-libs) it will be completely separate from the installed version of gcc, you can use the two side by side. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
