Building GCC 4.3.0 on Cygwin...

Thu Mar 22 13:28:00 GMT 2007

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/