X-Spam-Check-By: sourceware.org Message-ID: <46029F82.1604112@dessent.net> Date: Thu, 22 Mar 2007 08:23:46 -0700 From: Brian Dessent X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Building GCC 4.3.0 on Cygwin... References: <4602845D DOT 8020806 AT cwilson DOT fastmail DOT fm> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Charles Wilson wrote: > 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. Yes, that's pure FUD. > 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! Maintaining gcc packages seems to be a job that people take after some prodding. Just the other day Danny Smith said he only started doing it for MinGW because Mumit Khan (hope I spelled his name right) stopped. > 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: Danny said he's planning on releasing a MinGW 4.2 soon after 4.2 passes the RC stage and becomes released. > 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 These are all good points. There has recently been a similar thread on the MinGW list if anyone is interested in another similar but slightly different take on the issue. > (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 Yeah, tell me about it: $ ls -l libgcj* -rw-r--r-- 1 brian None 2.9M Feb 3 01:07 libgcj-tools.a lrwxrwxrwx 1 brian None 18 Feb 3 01:07 libgcj-tools.la -> ../libgcj-tools.la -rw-r--r-- 1 brian None 960 Feb 3 01:07 libgcj-tools.lai -rw-r--r-- 1 brian None 93M Feb 3 01:07 libgcj.a lrwxrwxrwx 1 brian None 12 Feb 3 01:07 libgcj.la -> ../libgcj.la -rw-r--r-- 1 brian None 947 Feb 3 01:07 libgcj.lai That's a 93 megabyte static archive. Brian -- 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/