Building GCC 4.3.0 on Cygwin...

Brian Dessent brian@dessent.net
Thu Mar 22 15:24:00 GMT 2007


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/



More information about the Cygwin mailing list