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: Are there plans to make gfortran a cygwin package?


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/


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