octave-maintainers
[Top][All Lists]
Advanced

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

Re: 3.2.0 release candidate 5: problems with blas/lapack


From: Jaroslav Hajek
Subject: Re: 3.2.0 release candidate 5: problems with blas/lapack
Date: Thu, 4 Jun 2009 07:09:08 +0200

On Thu, Jun 4, 2009 at 12:38 AM, Jean-Francois Cardoso <address@hidden> wrote:
>
>
> Jaroslav Hajek-2 wrote:
>>
>> On Tue, Jun 2, 2009 at 10:30 PM, Jean-Francois Cardoso <address@hidden>
>> wrote:
>>>
>>> Hello Jaroslav,
>>>
>>> I have problem building all 3.2.0 release candidates.
>>> The configure script does not detect properly the
>>> BLAS libraries.  This is happening on two machines of mine:
>>>
>>> 1) on my MacBook where ./configure spills out:
>>>
>>> [...]
>>> checking whether DDOT is called correctly from Fortran... yes
>>> checking whether CDOTU is called correctly from Fortran... no
>>> checking whether ZDOTU is called correctly from Fortran... yes
>>> configure: WARNING: A BLAS library was detected but found incompatible
>>> with
>>> your Fortran 77 compiler.
>>> [...]
>>>
>>> 2) on a Linux/Intel machine when I try to link with Intel's MKL.
>>>
>>> Again, BLAS detection fails on CDOTU.
>>>
>>>
>>> On both machines, I am able to compile successfully the 3.0.xx series,
>>> that is with proper detection of the local multithreaded BLAS libraries.
>>>
>>> Cheers, JF
>>
>> This is most likely happening if your Fortran compiler uses a calling
>> convention incompatible to your BLAS/LAPACK.
>> For instance, if you try to use gfortran + g77-compiled BLAS or vice
>> versa. Such an incompatibility can cause mysterious problems, that's
>> why this check was added.
>> If you're sure this is not the case, then please supply your config.log.
>>
>>
>
> Thanks for your reply.
> The blas detection problem is solved by adding a -ff2c switch.

It's obvious, then. Your BLAS is f2c-compatible (for g77 or older compilers).

> I have unfortunately no idea how my libraries are compiled.

You can usually tell by dumping out the dynamic dependencies of the
library. For instance, libgfortran is gfortran, libg2c is g77, libf2c
is f2c, etc.

> On Linux, I try to link to a prebuilt MKL library.

MKL comes in a number of flavors for most major compilers, including
gfortran. If you pick a compatible one, you won't need the switch.
IIRC, the ifort (native) version is also compatible with gfortran, but
you need to link in the ifort rtl explicitly.

> On MacOSX, I try to link to the native BLAS (Veclib, in Mac speech).
> On both systems, I had no problems with octave 3.0.xx.

In fact, the problems were identical, 3.0.x was just ignoring them.
Also, in some key places calls, 3.0.x was bypassing BLAS to avoid the
problems. Otherwise, things were mostly working, except mysterious
crashes when installing certain packages. 3.2.x does no longer bypass
the BLAS, so it simply wouldn't work OK with the incompatible
configuration. That's why configure provides no option to suppress
this test.
It's your configuration that is wrong, Octave is just detecting it.
BLAS and LAPACK are Fortran libraries (or at least
Fortran-compatible), and if they come pre-installed with the system,
they should be compatible with the system's Fortran compiler.

> Now, with ff2c, Linux+MKL seems to work fine.  However,
> on MacOSX, the build completes but there are several test failures
> which appear in sections unrelated to the BLAS.  Those are:
>
>  src/ov-struct.cc ....................................... PASS    9/16
> FAIL 7
>  src/pt-idx.cc .......................................... PASS    3/5
> FAIL 2
>  scripts/miscellaneous/getfield.m ....................... PASS    1/2
> FAIL 1
>  scripts/miscellaneous/orderfields.m .................... PASS    0/5
> FAIL 5
>  scripts/miscellaneous/setfield.m ....................... PASS    1/2
> FAIL 1
>  test_struct.m .......................................... PASS   38/44
> FAIL 6
>
> The build script is as follows:
> ================================
> export CPPFLAGS="-I/usr/local/include/readline"
> export LDFLAGS="-L/usr/local/lib"
> export FFLAGS="-ff2c" ; ## for octave 3.2.0
> ###   Where has gcc_select gone ?
> export CC=gcc-4.2
> export CPP=cpp-4.2
> export CXX=g++-4.2
> export CXXCPP=cpp-4.2 ##
> ./configure
> make -j2
> ================================
> The fortran compiler is gfortran 4.4.0
> All libraries are native (except a locally compiled readline)
> to an uptodate OSX 10.5.7 system.
>
> Let me know if I can help by providing (portions of) log files
> for the above test failures (I am reluctant to post
> fntests.log or config.log which are large files).
>
> Cheers, JF
>

Well you can maybe upload them somewhere and post a link? In any case,
if you use "test verbose", Octave will dump the code blocks that are
failing, so that you can quickly isolate a failing testcase.

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
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]