Mail Archives: cygwin/2007/03/22/10:24:23
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/
- Raw text -