Angelo Graziosi wrote:
It is almost a month that the build og gcc-core 4.3.0 on Cygwin is broken:
The last 4.3.0 source that builds fine is GCC-4.3.0-20070224-trunk-122292.
The strange thing is not that a development version of GCC is broken, but
that there is NOT much will to solve it for CYGWIN,
http://gcc.gnu.org/ml/fortran/2007-03/msg00047.html
http://gcc.gnu.org/ml/fortran/2007-03/msg00070.html
http://gcc.gnu.org/ml/fortran/2007-03/msg00085.html
I'm sorry, but the concerns expressed in the messages above are rank
paranoia. *Microsoft* has nothing to do with the lack of operable
modern gcc's on windows, and there is no conspiracy to break gcc on cygwin.
To the contrary, cygwin is listed as a secondary platform for gcc-4.2,
and mingw was just added as a secondary platform in its own right for
gcc-4.3. This means that:
http://gcc.gnu.org/gcc-4.3/criteria.html --
<quote>
Our release criteria for the secondary platforms is:
* The compiler bootstraps successfully, and the C++ runtime
library builds.
* The DejaGNU testsuite has been run, and a substantial majority
of the tests pass.
</quote>
So broken bootstrap on cygwin is a *release blocker* for 4.3 (also for
4.2)! So much for the grand anti-cygwin Microsoft/gcc conspiracy.
The main problem with gcc/cygwin/mingw is the following (and I mean no
criticism of current or past cygwin maintainers of gcc):
(1) the official cygwin gcc packages lag far behind current development
(2) so very few people are actually using, on cygwin, versions of gcc
that are under active development
(3) so there are few bug reports or especially bug fixes being
contributed to the gcc developers for cygwin
(4) and therefore gcc trunk's cygwin support is slowly bitrotting
Re: Can't bootstrap gcc 4.2 RC1 on cygwin: gcc/boehm-gc/misc.c:680:
undefined reference to `_GC_get_thread_stack_base'
http://gcc.gnu.org/ml/gcc/2007-03/msg00791.html
to the point that you get a broken bootstrap...
Now, because cygwin is a secondary platform and *must* at least
bootstrap before 4.3 (or 4.2, see RC1 issue above) can be released, I'm
sure that will be fixed -- must be fixed -- eventually (gcc-4.3 is only
in Stage 1 development, so there's some time yet before it will be
considered for release).
About (1), above: there are some good reasons for cygwin (and mingw)
being stuck on 3.4.x rather than 4.0, 4.1, or even 4.2/4.3 (which are
not yet officially released, being in Stage 3 and Stage 1 development
respectively). First, of course, there was a period where gcc on cygwin
was unmaintained. Recently Dave has taken over (thanks, Dave!) and he's
published a few new releases -- still 3.4.x-based, but I'm sure he's
actively working on 4.x stuff. Dave is active on the gcc mailing lists,
so...
But having an active maintainer is one thing. The actual codebase of
gcc is another: Back in the days of yore, cygming gcc actually existed
on its own branch. It had a lot of tweaks relative to mainline. When
mainline 4.0 came out, it was massively different than mainline 3.4 and
had very few of those cygming-specific tweaks: in fact, it didn't work
very well at all on cygwin/mingw, especially the additional frontends.
Porting all the cygming tweaks to the new 4.0 mainline was going to be
very hard, and that all happened right when we (cygwin) had no
maintainer to manage/push the effort!
The MinGW guys specifically said they were going to "skip" 4.0 entirely,
waiting for things to get better in the 4.1 release. Well, 4.1 was a
bit better, but it does not yet have all the bells and whistles that are
really needed on mingw/cygwin. 4.2 will probably be a bit better still:
but here's the big thing:
For C++ and Java at least, gcc 4.0/4.1/4.2/4.3 STILL have yet to
incorporate some version of the exceptions-across-DLLs patch (e.g. even
with gcc-trunk, on windows you cannot throw a C++ exception in a DLL and
catch it the executable). This is because the originator of that patch
considers it a hack, and as it is intimately tied to the old 3.4.x gcc
internals will take quite a bit of work to port to the new 4.x
internals. Further, there exists a better solution: if we could build a
DLL versions of the various runtime libraries, the problem would go away.
Well, THAT is a long standing wishlist item on cygwin/mingw itself.
And, it requires that the entire gcc codebase be converted to modern
autotools -- a project that has been on-going now for almost two solid
years, but is finally nearing completion: the whole codebase now uses
autoconf-2.59 (as opposed to a mishmash of autoconf-2.13 and various
later versions). The whole codebase now uses automake-1.9 where it uses
automake at all (as opposed to a mishmash of various flavors from 1.4p5
to 1.8). There's one last piece:
gcc uses a forked and heavily modified version of libtool-1.4.x which
only barely supported cygwin/mingw. There is an on-going effort to
replace the libtool used in the gcc tree with a modern version
(specifically, the top-of-tree development version of libtool, which
will be released eventually as libtool-2.0). This effort by Steve
Ellcey and others is recent:
Updating libtool in GCC and srctree
http://gcc.gnu.org/ml/gcc/2007-03/msg00293.html
AC_LIBTOOL_WIN32_DLL for libgfortran
http://gcc.gnu.org/ml/gcc/2007-03/msg00333.html
libgfortran Makefile question (using latest libtool)
http://gcc.gnu.org/ml/gcc/2007-03/msg00798.html
Once this effort is completed, it will -- at least theoretically -- be
possible to build runtime libraries as DLLs on cygwin/mingw, which will
solve the exceptions-across-DLL boundaries problem, which is important
for the C++ and Java front ends.
Then, there will still be a few other issues:
(1) Dwarf2 vs. SJLJ exceptions: the latter is required for strict
compatibility with Win32, as dw2 exceptions thrown by functions passed
to Win32 as callbacks cannot be caught [this is a separate issue from
the exceptions-across-DLL boundaries issue mentioned above] Fixing this
DW2/win32callback thing is on the list as a possible Google Summer of
Code item for 2007. We could stick with SJLJ, but the desire for dw2 is
that it is MUCH faster than SJLJ -- to the point where it is almost
required for a decent performance with java. Also, DW2 exceptions are
not really supported at all on win32 without patching:
[PATCH] Dwarf 2 Unwind frames for mingw32/cygwin
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00133.html
(2) the java runtime library is huge, and to even attempt to link it as
a DLL requires massive (>1GB) amounts of RAM. I seem to recall that
this is due to inefficiencies in the way ld creates import libraries, so
perhaps some work in binutils may be necessary so that normal humans
with regular machines can build the java frontend and runtimes...see the
last bit of this message:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00133.html
(3) There are some pending mingw issues which don't directly affect
cygwin, but since a lot of the win32 development is interlinked there
can be indirect effects:
RE: [Patch/C++]: Use dllonexit for static destructors on mingw32
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01612.html
(4) And, of course, the bootstrap issue that prompted your message
So, to sum up: there are a lot of contributing factors to the
difficulties we are all experiencing with gcc 4.0+ on cygwin/mingw, but
a Microsoft conspiracy is not one of them. And, work is ongoing to
solve these issues...after several years, it seems that we're almost there.
--
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/
