octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave & Fortran continued


From: Jaroslav Hajek
Subject: Re: Octave & Fortran continued
Date: Tue, 16 Dec 2008 10:27:00 +0100

On Tue, Dec 16, 2008 at 9:54 AM, Michael Goffioul
<address@hidden> wrote:
> On Fri, Dec 12, 2008 at 3:42 PM, Michael Goffioul
> <address@hidden> wrote:
>> On Fri, Dec 12, 2008 at 2:27 PM, Jaroslav Hajek <address@hidden> wrote:
>>> hello,
>>>
>>> further to the recent discussion about Octave's Fortran compiler
>>> support, here's an important (IMHO) update:
>>> I've just noticed that the unbelievable thing actually happened and
>>> LAPACK moved (apart from a number of improvements etc) to Fortran 90,
>>> so F90 compiler is officially required to build LAPACK 3.2. Since
>>> Octave probably really wants to keep up with LAPACK as it relies
>>> fundamentally on it, we should IMHO think about ways to overcome the
>>> limitations of the MSVC/Windows platform that keep Octave stuck with
>>> the subset of Fortran that f2c supports.
>>> Hmm, another clear signal that Fortran is not dead.
>>>
>>> So, is it really impossible to use gfortran or g95 on Windows together
>>> with MSVC?
>>
>> Definitely no idea...
>> I'll have to give it a try.
>
> Just for the record, mixing code gfortran and MSVC is a tough beast
> and up to now I didn't succeed. Doing the same with g77 was easier
> as MSVC could link in g77-compiled objects by also linking to libf2c
> (compiled with MSVC). This provided the needed runtime functions
> required by g77-compiled code.
>
> Given all these problems, I decided to give MinGW a try, using the
> latest version based on gcc-4.3.0. But recompiling all deps takes
> time, given the only 30min of free time I have in the evening...
>
> Michael.
>

Thanks for trying. You have a lot of time,  I guess. Certainly for
3.2.x we'll stay with lapack 3.1.x.
I didn't check, but I reckon that so far there are very few LAPACK
routines that really need F90.
But in time, their number will probably increase - see LAPACK working notes.
Other libcruft stuff may benefit, too - we may get rid of
non-reentrancy of some of the Fotran-based routines (quad, lsode,
daspk etc), (is it woth the effort? opinions?)

regards

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

[Prev in Thread] Current Thread [Next in Thread]