darwin may lose primary target status on FSF gcc

Jack Howarth howarth at bromo.med.uc.edu
Sat Sep 19 10:15:16 PDT 2009


On Sat, Sep 19, 2009 at 01:03:26AM -0700, Toby Peterson wrote:
> On Fri, Sep 18, 2009 at 17:43, Jack Howarth <howarth at bromo.med.uc.edu> wrote:
> > On Fri, Sep 18, 2009 at 05:31:40PM -0700, Toby Peterson wrote:
> >>
> >> Given current reality, you're probably better off contributing to
> >> llvm-gfortran... or better yet, a native fortran front-end for llvm.
> >> FSF gcc is barely relevant on our platform these days.
> >>
> >> - Toby
> >
> > Toby,
> >   I created the fink llvm/llvm-gcc42 packages to provide
> > them with a llvm-gfortran. However the gfortran in llvm-gcc42
> > is just that (locked at the gcc 4.2.1 release because it
> > was the last GPLv2 release that Apple will accept). It has
> > much worse performance than the current gfortran in gcc 4.4.0,
> > has fewer features and significant portions of the newer
> > features aren't working properly. The chances of llvm-gcc
> > being updated to a newer release are basically zero and
> > there is no clang related fortran compiler at all. You
> > work with the hand your dealt...and for us that is trying
> > to keep the wheels on FSF gcc for darwin as long as possible.
> > Actually gcc 4.4.1 has excellent testsuite results on darwin10.
> > Also look at...
> >
> > http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg18166.html
> > http://archive.netbsd.se/?ml=fink-devel&a=2009-03&m=10250229
> >
> > where I benchmarked the various gcc compilers on Intel darwin.
> > Lastly, if you check the table at...
> >
> > http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/
> >
> > you will see how really bad it would be to have to rely on
> > g95 even if it built on darwin10 (almost 3 times slower
> > than current gfortran).
> 
> That's why I suggested *contributing* to llvm-gfortran or a native
> front-end. If it lags behind, make it better. FSF gcc just doesn't
> have much of a future on our platform...
> 
> - Toby

Toby,
    The llvm-gfortran project will be a lost cause in the long run
mainly because it is trapped on a most inconvenient source base.  The
GPLv3 license came into effect just as gfortran development was beginning
to show massive progress. The FSF gcc used for llvm-gcc will likely
never be updated because of the GPLv3 issue so its gfortran is trapped
in a time warp. The most promising approach would be a native fortran
compiler for clang but no such project exists yet. I can only work with
the possible.
         Jack
ps You do realize that we are using gcc 4.2.1 (and not 4.2.4 or a later
gcc release) only because of the GPLv3 license. Few people are aware
but Apple's programmers (who are the FSF darwin maintainers) are not 
allowed to read the gcc mailing lists or the gcc source code since
GPLv3 came into effect. They can only review and approve patches submitted
for the FSF gcc that impact the darwin port. Fortunately that has
allow me to keep the wheels on FSF gcc on darwin so far (knock on wood).



More information about the macports-dev mailing list