X-Spam-Check-By: sourceware.org X-ORBL: [68.125.128.180] Message-ID: <441BAEF9.8090404@myrealbox.com> Date: Fri, 17 Mar 2006 22:55:53 -0800 From: Tim Prince Reply-To: tprince AT computer DOT org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 MIME-Version: 1.0 To: Charles Wilson CC: cygwin AT cygwin DOT com Subject: Re: GCC 4.x+ References: <4418AB38 DOT B7D87B36 AT dessent DOT net> <441B8AB3 DOT 9080308 AT cwilson DOT fastmail DOT fm> In-Reply-To: <441B8AB3.9080308@cwilson.fastmail.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/