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/