GCC 4.x+

[Tim Prince]

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.
<ot>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/