On Sat, Sep 19, 2009 at 10:15, Jack Howarth <[email protected]> wrote: > On Sat, Sep 19, 2009 at 01:03:26AM -0700, Toby Peterson wrote: >> On Fri, Sep 18, 2009 at 17:43, Jack Howarth <[email protected]> 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/[email protected]/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.
I'm not sure how what I'm suggesting is impossible. Hard, maybe, but impossible? > 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). I'm fully aware of the evils of GPL. - Toby _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
