This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building GCC 4.3.0 on Cygwin...

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,

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: --
  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.

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'

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

AC_LIBTOOL_WIN32_DLL for libgfortran

libgfortran Makefile question (using latest libtool)

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

(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:

(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

(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.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]