dll and static lib inconsistencies

[totte_karlsson]

Hi,
I just started using lapack with Visual Studio and Borland compilers, and have some problems. (I leave out the Borland ones for now)

a) compiling clapack 3.2.1using CMake -> seem to only give me a static lib (is that right?) And the "install" target don't work.

b) downloaded the 32bits dll's from http://icl.cs.utk.edu/lapack-for-window ... index.html (in the docs it says you need libgfortran-3.dll. But that file don't exists in a cygwin installation. On my system it is called cyggfortran-3.dll. I just copied this and named it libgfortran-3.dll and that seemed to work?

Now, my application, that only uses two functions dgeqp3_ and dorgqr_ give different result, depending on if I link with the static libe (3.2.1) or using the DLL.

With the static lib, my app runs fine, but the result is different from when linking with the DLL. (I'll try to post output later on here, unfortunately the application is a little convoluted at the moment)

When linking with the DLL, everything works fine, except when the application exits. When it exits, the app has to be manually killed, and a core dump is emitted. I'm using Visual Studio 2010.

Any feedback on this is welcomed. Have anyone else observed the core dump problem with the prebuilt dll's?

Also, why are not the corresponding header files not published together with the lib and the dll on the lapack-for_windows page?. Its crucial that they are matching, I would think.

Cheers,
Totte

[admin]

Dear Totte,
First dll and lib are not matching because the dll build is not yet officially released and modifications have been made to LAPACKE since the 3.4.0 release.
And you are talking about the CLAPACK lib, that makes sense as CLAPACK is no longer supported.
We released last November a new C Standard LAPACK Interface in collaboration with INTEL (see http://www.netlib.org/lapack/#_standard ... for_lapack)

dlls are not based on Cygwin but Mingw. libgfortran-3.dll is part of Mingw.
Yes, it makes sense to post the header files online. Will do.

We do not support the Windows Borland Compilers at the moment, only VS C Compiler.

dgeqp3_ and dorgqr_ give different result

That is more annoying, I don't think we made any change to those routines between 3.2.1 and 3.4.0.
Could you send a piece of code so I try to reproduce the problem?

[totte_karlsson]

>First dll and lib are not matching because the dll build is not yet officially released and modifications have been made to LAPACKE since the 3.4.0 release.
>And you are talking about the CLAPACK lib, that makes sense as CLAPACK is no longer supported.
ok, I'll stay away from those links then.

>We released last November a new C Standard LAPACK Interface in collaboration with INTEL (see http://www.netlib.org/lapack/#_standard ... for_lapack)
I will check this out. That would need compilation of FORTRAN from source I assume.

>dlls are not based on Cygwin but Mingw. libgfortran-3.dll is part of Mingw.
I see. I somehow thought Mingw was part of Cygwin.

>Yes, it makes sense to post the header files online. Will do.
Cool,

>We do not support the Windows Borland Compilers at the moment, only VS C Compiler.
OK. I hope I can help getting it compiling with borland perhaps.

>dgeqp3_ and dorgqr_ give different result
>That is more annoying, I don't think we made any change to those routines between 3.2.1 and 3.4.0.
>Could you send a piece of code so I try to reproduce the problem?
I will be back to this one in a few weeks. I'll try to rip out the piece that gives me different result. Its part of a bigger application..

Thanks for answers!
totte

[Julien Langou]

dgeqp3_ and dorgqr_ give different result

In LAPACK 3.1.1 and before, DGEQP3 was using DLARFG (it was using DLARFG indirectly but it was using it).
During LAPACK 3.2.0 and 3.2.1, we had DGEQP3 using DLARFP.
For LAPACK 3.2.2 and after, we revert back from using DLARFG in DGEQP3.

The output of DGEQP3_3.2.1 and DGEQP3_3.4.0 are therefore not the same.

But this is should not be an issue ... The functionality should still work.

(The only difference is in the diagonal entries of the R factor.
3.2.0 and 3.2.1 was guaranteeing them nonnegative.)

I do not think DORGQR has had any change.

(Of course if you feed to DORGQR the different results from DGEQP3_3.2.1 or DGEQP3_3.4.0 you would get different results from DORGQR.)
(But still, in any cases 3.2.1 or 3.4.0, you should get the Q associated with the R from the routine.)

Cheers,
Julien.

[totte_karlsson]

Thanks for the clarification.
Any hint on when those headers may be available?

Thanks,
Totte

[admin]

Header files are been posted on http://icl.cs.utk.edu/lapack-for-window ... #libraries
Julie