X-Spam-Check-By: sourceware.org Message-ID: <45AA23B4.FD474C0E@dessent.net> Date: Sun, 14 Jan 2007 04:36:04 -0800 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: Are there plans to make gfortran a cygwin package? References: <45A9C26C DOT 5050800 AT manfred-ursprung DOT de> <002f01c737d1$cc8e9f60$6401a8c0 AT aquitania> 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 Gene Ruzicka wrote: > There is a gfortran build for cygwin, which is readily available > on the Web, but --- please correct me if I'm mistaken --- gfortran > is not yet a cygwin package. Are there pany plans to make it one? > Cygwin still comes with g77, but Gnu has stopped supporting that. [ Please don't commandeer threads for unrelated topics. Just replying and changing the subject does not create a new thread, which means your reply stays attached to the old thread in the web archives and in the inboxes of anyone using a proper threaded email reader. ] It's a complicated question. Firstly, you can't just single out gfortran, as it is just one part of gcc 4.x, which contains a large number of components: C, ObjC, ObjC++, C++, Java, Ada, Fortran; and then the non-FSF frontends: D and pascal; and the runtime libraries: libgcc, libstdc++, libgcj, libgfortran, libjava, etc. The way the compiler is designed it can get very tricky to mix and match these components from different versions of the compiler, and so from a package maintainer standpoint it's kind of an all-at-once-or-nothing affair. It's great that "some guy somewhere offers a gfortran that you can download" but that's not the same thing as a distro which can't just offer bits and pieces of gcc 4 ad hoc, it really has to integrate. Another problem is that the current 3.4 gcc packages do not have a version as part of their name, i.e. the package names are just "gcc", "gcc-g++", and so on. This means only one version can be installed at any given time, so any gcc 4.x package would probably need to be renamed to "gcc4", "gcc4-g++", etc. (and likewise with naming the binaries themselves) so that it can be installed in parallel to the current version, because gcc 4.x is such a radically different compiler and there is a *lot* of code out there that still does not built with it (Cygwin itself will not build under gcc4 the last time I tried.) So this means a lot more work and effort on the part of the maintainer. Yet another problem is that not all parts of gcc 4.x are really ready for prime time yet on Cygwin/win32. If you are just doing straight C and nothing fancy then it's probably fine. But what about more involved things? Throwing and catching exceptions across DLLs? Shared libstdc++? DW2 or SJLJ? Throwing an exception in a win32 callback? All of these things have been traditionally very problematic and require extra work to get right, and for whatever reason the patches always seem to remain out of tree and not accepted upstream, which means even more maintainer work to track down these issues, maintain these out of tree patches, etc. And that is just for C/C++ which are the best tested of the front ends. I don't have any personal knowledge of the current state of 4.x gcj but from what I've read it's a total mess right now on Win32, not even close to being usable. So, in summary: - gfortran is only one component of a much larger gcc, and from a package maintainer standpoint you can't cherry pick - it's a lot of work to package and test a complex component like this even on "first class" systems like linux - win32 always lags behind in terms of gcc development and many things don't build or work fully without out-of-tree patches - gcc 4 is radically different from gcc 3.x and much has changed, and again very few gcc developers seem to use or care much about win32 - at the moment the only person maintaining gcc packages is the adoptive maintainer Dave Korn who stepped in after Gerrit became too busy - a broken compiler does nobody any good, better to have nothing than something with flaws There have naturally been many threads dealing with the status of the Cygwin gcc 4.x in the past, and I suggest you take a look at them. My opinions above are mine and don't necessarily represent anyone else's, but I think that everyone can agree that getting gcc4 packages ready for prime time is a big task that may not happen for some time. 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/