Calling Clapack functions in Visual Studio 2008 / Windows XP

[jocheno]

No luck yet. Still getting the same error message. I tried to install some kind of lib package for cygwin, but including the "libtool" in the "devel" category didn't make any difference. There is a lib.exe programm by Visual Studio so I suppose by running the vcvars32.bat you tell Cygwin where to find these things!?

Well, any idea what I am missing to properly build the libgoto_core2_r1.26.lib file?

Jochen

[jocheno]

I copied the lib.exe from the VisualStudio/VC/bin folder directly into the exports folder and received an error message that the LINK command was not found.

I therefore also copied the link.exe from the VisualStudio/VC/bin folder directly into the exports folder and now I am stuck with the following:
dllwrap -mno-cygwin -o libgoto_core2-r1.26.dll --def libgoto_core2-r1.26.def --entry _dllinit@12 -s dllinit.o ../libgoto_core2-r1.26.a
lib /machine:i386 /def:libgoto_core2-r1.26.def
make: *** [libgoto_core2-r1.26.dll] Error 53

I wasn't able to find an explanation about what is the meaning of "Error 53" in make...

Jochen

[graphicsRat]

The problem is that although you've run vsvars32.bat, Cygwin still can't find the path to the Visual Studio tool called lib. That's what make originally complained about. The Cygwin path to the command lib on my machine is:
/cygdrive/c/Program Files/Microsoft Visual Studio .NET 2003/VC7/BIN/link

This means you can go about it two ways:
(you may want to type "make clean" to get rid of the files generated during previous failed build attempts)

1. Add the path to the command link (i.e. /cygdrive/c/Program Files/Microsoft Visual Studio .NET 2003/VC7/BIN/) to your Cygwin path and then run "make dll" in Cygwin.

OR

Note: the next option although considerably simpler, (probably) requires Cygwin command such as "ps" and "make" to work on the Windows command line prompt. Those commands work on my machine and I'm wondering if its because of something I installed on my machine and have forgotten to mention. I'll get back to you on this

2. run "make dll" in what's called the "Visual Studio command prompt". The Visual Studio command prompt is basically a version of of the command prompt (cmd) that knows where all the Visual Studio tools such as link are. Launch the Visual Studio command prompt from:
Start Menu -> Programs -> Microsoft Visual Studio -> Visual Studio Tools -> Visual Studio Command prompt

[jocheno]

The second option (Visua Studio command prompt) worked! I have successfully built the BLAS library! Thank you so much.

I just have to note, that in order for this to work, I had to include the "d:\programme\cygwin\bin" path in the windows path variable!

The first option failed, because I wasn't able to manually modify the Cygwin path. I tried to manually include the path to Visual Studio in the "cygwin\etc\profile" file. But when I had changed and saved the path variable, cygwin didn't execute properly anymore!? How do you properly modify the Cygwin path?

But oh well, I have a optimised BLAS library now, so I can go ahead and test out Lapack in C++ now!

I will probably come back to you, as I don't expect it to work out smoothly on the first try. But again: Thank you so much for your valuable help! Maybe you can include some of my questions (or your answers to those questions) in your step-by-step instructions!?

Take care,

Jochen

[graphicsRat]

The second option (Visua Studio command prompt) worked! I have successfully built the BLAS library! Thank you so much.

Yay! :)

I just have to note, that in order for this to work, I had to include the "d:\programme\cygwin\bin" path in the windows path variable!

Thanks. The good people at the Cygwin newsgroup confirm that this is the correct thing to do.

The first option failed, because I wasn't able to manually modify the Cygwin path. I tried to manually include the path to Visual Studio in the "cygwin\etc\profile" file. But when I had changed and saved the path variable, cygwin didn't execute properly anymore!? How do you properly modify the Cygwin path?

Have you messed up your Cygwin path then? Best post on the Cygwin mailing list

But oh well, I have a optimised BLAS library now, so I can go ahead and test out Lapack in C++ now!

An optimized BLAS really does make all the difference. I remember the first time I tried to solve a 900 by 900 system with GSL, which internally uses LAPACK with the reference BLAS by default. My laptop thrashed all night (for 8 hours) and still did not complete the task (I had to terminate the process). With the reference BLAS, my laptop now solves the same problem in under 10 seconds! ... My laptop can also solve up to 7000 by 7000 matrix systems (that's almost 5 million elements!) in about 3 mins!

Maybe you can include some of my questions (or your answers to those questions) in your step-by-step instructions

Indeed I shall. Can you please confirm that step 4 of "Compiling GotoBLAS" (i.e. renaming the *.a files) is not necessary.

Thanks.

[jocheno]

Yes, renaming is not only not necessary but leads to errors, as the makefile references to the libgoto[...].a file!

I can now successfully compile a Visual Studio project (Win32 console application) with the C++ sample code you were giving. However, when executing the corresponding .exe file, I get an error:
Unbehandelte Ausnahme bei 0x6995782f in Lapack_text.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0xffffffff.

If I start the debugger, it shows the error to happen in the crtexe.c file during the WPRFLAG definition:
#ifdef WPRFLAG
__winitenv = envp;
mainret = wmain(argc, argv, envp); The debugger halts here!
#else /* WPRFLAG */
__initenv = envp;
mainret = main(argc, argv, envp);
#endif /* WPRFLAG */

If I debug directly in Visual Studio, the error happens when calling the dgesv_ routine in _tmain:

Code: Select all

#include "stdafx.h"
#include <stdio.h>


extern "C" void dgesv_(const int *N, const int *nrhs, double *A, const int *lda, int
   *ipiv, double *b, const int *ldb, int *info);

extern "C" void dgels_(const char *trans, const int *M, const int *N, const int *nrhs,
    double *A, const int *lda, double *b, const int *ldb, double *work,
    const int * lwork, int *info);

int _tmain(int argc, _TCHAR* argv[])
{
    /* 3x3 matrix A
     * 76 25 11
     * 27 89 51
     * 18 60 32
     */
    double A[9] = {76, 27, 18, 25, 89, 60, 11, 51, 32};
    double b[3] = {10, 7, 43};

    int N = 3;
    int nrhs = 1;
    int lda = 3;
    int ipiv[3];
    int ldb = 3;
    int info;
   
                          dgesv_(&N, &nrhs, A, &lda, ipiv, b, &ldb, &info);

    if(info == 0) /* succeed */
   printf("The solution is %lf %lf %lf\n", b[0], b[1], b[2]);
    else
   fprintf(stderr, "dgesv_ fails %d\n", info);

   char my_char;
   my_char = getchar();

    return info;

}

The sample code didn't foresee to include any additional header files at the beginning. How does the compilier know where to find dgesv_ and dgels_ then? Well, there aren't any header files in the Lapack 3.1.1 installation anyway...

Note: I have added additional dependencies libgoto_core2-r1.26.lib and lapack.lib in the linker options and have provided the path to the Lapack library folder in the general Visual Studio options -> Projects -> VC++ folders -> Library folders. No includefiles!?

In the Lapack 3.1.1. installation root there is a Visual Studio Solution folder. Anything I can take or learn from those files?

Cheers,

Jochen

[graphicsRat]

Yes, renaming is not only not necessary but leads to errors, as the makefile references to the libgoto[...].a file!

Thanks. I'll remove that step then.

I can now successfully compile a Visual Studio project (Win32 console application) with the C++ sample code you were giving. However, when executing the corresponding .exe file, I get an error:
Unbehandelte Ausnahme bei 0x6995782f in Lapack_text.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0xffffffff.

If I start the debugger, it shows the error to happen in the crtexe.c file during the WPRFLAG definition:
#ifdef WPRFLAG
__winitenv = envp;
mainret = wmain(argc, argv, envp); The debugger halts here!
#else /* WPRFLAG */
__initenv = envp;
mainret = main(argc, argv, envp);
#endif /* WPRFLAG */

Clearly, you've created a console application project with the customary Visual Studio gunk (highlighted in blue). Just create an empty Visual Studio console project, add the sample file to it, and specify the linker settings.

The sample code didn't foresee to include any additional header files at the beginning. How does the compilier know where to find dgesv_ and dgels_ then? Well, there aren't any header files in the Lapack 3.1.1 installation anyway...

Note: I have added additional dependencies libgoto_core2-r1.26.lib and lapack.lib in the linker options and have provided the path to the Lapack library folder in the general Visual Studio options -> Projects -> VC++ folders -> Library folders. No includefiles!?

Your last question first. Include files are not necessary for two reasons. First LAPACK is written in Fortran, not C or C++. As such you cannot include anything of the LAPACK source in your program. Two, LAPACK has already been compiled into a library, which is linkable with the object file produced by the compiler. (Remember that object files and library files are OS, language-agnostic file formats that do NOT retain information about the programming languages they were written in.)

Now to your first question. The LAPACK routine names (e.g. DGESV_) at the start of the sample files are function prototypes or declarations. They inform the compiler that the corresponding functions exist, even though they are not defined in the current source. (You and I know that they are defined in the LAPACK library that will be linked with.) As such the compiler takes our word for it, and compiles the source into an object file, even though some of the declared functions (also referenced in the source) are not presently available. The linker must however be able to find such functions while linking the object file generated by the compiler with the LAPACK library.

One final note about the prefix: extern "C". It is necessary to prepend this to the function prototype/declaration in order to prevent what's called "name mangling". You see, C++ compilers have the (necessary) habit of decorating the function names (with their arguments, in order to support overloading etc.). As a result of name mangling, a function declaration like: void Foo( char, int ) will be translated by the C++ compiler into something like "char_int_Foo" in the object file it generates. The problem with this is that, name "char_int_Foo" may NOT exist in the library, although the undecorated name Foo might. (On the other hand, if the library were written in C++ and compiled appropriately, function names in the files would already be mangled.) Therefore because Fortran compilers do not mangle function/subroutine names, it is important to prevent the C++ compiler from mangling the names of LAPACK subroutines. This is the job of the prefix extern "C". The effect of this directive is to ask the C++ compiler to treat the declaration as a "C" function. Note: C compilers mangle function names. Result: the function name generated by the C++ compiler matches the unmangled name in the external library.

If you would like to see the LAPACK function names for yourself, run the following the "nm" command on the LAPACK (or any library) in Cygwin: e.g. nm lapackd.lib | less (The "less" command handles scrolling.)

Name mangling:
http://tinyurl.com/o64mdu
http://en.wikipedia.org/wiki/Name_mangl ... om_C.2B.2B

extern "C"
http://en.wikipedia.org/wiki/Extern

[jocheno]

Hey there!

Unfortunately, I still get an error message when running the .exe or when debugging my project: the debugger halts at the line where the dgesv_ routine is supposed to be called with the exact same error message as before:
Unbehandelte Ausnahme bei 0x6995782f in Lapak_test.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0xffffffff.

I generated an empty VS project, copied the sample code, and gave the BLAS (libgoto_core2-r1.26.lib) as well as the lapack.lib as additional dependencies and 'D:\Programme\LAPACK 3.1.1\lib\win32' as well as 'D:\Programme\GotoBlas\exports' as a paths to library files.

I also tried to change the lapack.lib to the lapackd.lib debugger library, but I still get the same error!?

The Cygwin nm command showed me some weired stuff that I didn't understand. I hoped that the nm command might give me the names of the library's routines that can be called from my C++ programm!?

This is the code of my lapak_text_main.cpp file (the only file in the project!):

Code: Select all

#include < stdio.h>

extern "C" void dgesv_(const int *N, const int *nrhs, double *A, const int *lda, int
   *ipiv, double *b, const int *ldb, int *info);

extern "C" void dgels_(const char *trans, const int *M, const int *N, const int *nrhs,
    double *A, const int *lda, double *b, const int *ldb, double *work,
    const int * lwork, int *info);

int
main(void)
{
    /* 3x3 matrix A
     * 76 25 11
     * 27 89 51
     * 18 60 32
     */
    double A[9] = {76, 27, 18, 25, 89, 60, 11, 51, 32};
    double b[3] = {10, 7, 43};

    int N = 3;
    int nrhs = 1;
    int lda = 3;
    int ipiv[3];
    int ldb = 3;
    int info;
   
    dgesv_(&N, &nrhs, A, &lda, ipiv, b, &ldb, &info);

    if(info == 0) /* succeed */
   printf("The solution is %lf %lf %lf\n", b[0], b[1], b[2]);
    else
   fprintf(stderr, "dgesv_ fails %d\n", info);


    return info;
}

I am thankful for any further hints what might still be wrong!?

Jochen

[graphicsRat]

Unfortunately, I still get an error message when running the .exe or when debugging my project: the debugger halts at the line where the dgesv_ routine is supposed to be called with the exact same error message as before:
Unbehandelte Ausnahme bei 0x6995782f in Lapak_test.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0xffffffff.
...
The Cygwin nm command showed me some weired stuff that I didn't understand. I hoped that the nm command might give me the names of the library's routines that can be called from my C++ programm!?

The command nm - list symbols from object files, and should give you an idea of what sort of names your LAPACK subroutines have e.g. are the case sensitive. For example on my laptop (I'm still using version 3.1.1 of LAPACK) I get the following:

$ nm LAPACKd.lib | grep DGESV
00000000 T _DGESV
00000010 b DGESVX$NORM
00000000 T _DGESVX
00000000 b DGESVD$DUM
00000000 T _DGESVD

With GotoBLAS:

$ nm libGotoBLAS.lib | grep DGESV
00000000 T _DGESV
00000000 I __imp__DGESV

You may therefore wish to try uppercase names for the solver, if the output of DGESV suggests that the names are uppercase. However, I'm not entirely sure this is the cause of the problems you're having. Why? If the lowercase name you specified in your declaration wasn't contained in the library, the linker would have failed. I'll let you know if I come up with any other possible causes. However, for now check your library names.

[jocheno]

I am also using Lapack 3.1.1, and this is what I get for lower and upper case DGESV:

$ nm LAPACKd.lib | grep DGESV
00000000 T _DGESV
00000010 b DGESVX$NORM
00000000 T _DGESVX
00000000 b DGESVD$DUM
00000000 T _DGESVD

$ nm LAPACKd.lib | grep dgesv
Debug/dgesvx.obj:
Debug/dgesvd.obj:


For my (optimised) BLAS library I get :

$ nm libgoto_core2-r1.26.lib | grep DGESV
00000000 T _DGESV
00000000 I __imp__DGESV

and:
$ nm libgoto_core2-r1.26.lib | grep dgesv
00000000 I __imp__dgesv
00000000 T _dgesv
00000000 I __imp__dgesv_
00000000 T _dgesv_

As I am calling the lower case functions from C++ (with an underscore at the end, see the sample code), I suppose that the BLAS function is called. As the linker doesn't complain there is probably something wrong with the blas library. I will try to use the default BLAS library for a start and if that works I might have to rebuild the optimised BLAS library.

Do the LAPACK and the BLAS dgesv routines differ, i.e. does it matter, which one I am calling (except for computational time)?

1 hour later: Ok, I still understand less than I would like to ;-) I wasn't able to find the default/reference BLAS library; I thought there was a ...blas.lib file somewhere that I could then add to the additional dependencies in Visual Studio. I only found the blas.lib and blasd.lib files in the Lapack_3.1.1\lib\win32 folder. However, corresponding to the Cygwin nm command, these two libraries do not include any dgesv or DGESV routine!? I will rebuild my gotoBLAS implementation and see what happens.

Best regards,

Jochen

[jocheno]

Ok, I am starting to feel really stupid. I am not making any progress but instead I fall back to a stage that I left about a week ago.

I tried to rebuild the Blas library, following the exact same procedure as before. But when trying to build the .dll and .lib by executing "make dll" within the VS command prompt, I first receive this message:
.gensymbol win2k dummy 0 X86 > libgoto_core2-r1.26.def
/bin/sh: ./gensymbol: /usr/bin/perl: bad interpreter: No such file or directory
make: *** [libgoto_core2-r1.26.def] Error 126

During the execution of "make dll" for the first time, it seems that the definition file libgoto_core2-r1.26.def is generated, thus when typing "make dll" for the second time, now there is a different error message:
[...]
dlltool: Syntax error in def file libgoto_core2-r1.26.def:0
dlltool: Syntax error in def file libgoto_core2-r1.26.def:0
lib /machine:i386 /def:libgoto_core2-r1.26.def
Microsoft <R> LIbrary Manager [...]

Bibliothek "libgoto_core2-r1.26.lib" und Objekt "libgoto_core2-r1.26.exp" werden erstellt.


I did everything as before, and I receive those syntax errors in the definition file!? I saw that I had the same two "Syntax error" messages before (see one of my posts above), with the difference that back then I was missing the path to the lib.exe, thus I didn't care so much about the two syntax errors!?

A .dll and a .lib file are built, but they are very small and the "nm" command shows me, that they are practically empty:
$ nm libgoto_core2-r1.26.lib

libgoto_core2-r1.26.dll:
00000000 i .idata$2
00000000 i .idata$4
00000000 i .idata$5
00000000 i .idata$6
0093521e a @comp.id
00000000 I __IMPORT_DESCRIPTOR_libgoto_core2-r1.26
U __NULL_IMPORT_DESCRIPTOR
U ^libgoto_core2-r1.26_NULL_THUNK_DATA

libgoto_core2-r1.26.dll:
0093521e a @comp.id
00000000 I __NULL_IMPORT_DESCRIPTOR

libgoto_core2-r1.26.dll:
0093521e a @comp.id
00000000 I ^libgoto_core2-r1.26_NULL_THUNK_DATA

I don't know. I am close to giving up, but I need this solver so badly... I hope you are not giving up yet!? ;-)

Frustrated greetings from Hamburg!

Jochen

[graphicsRat]

I am also using Lapack 3.1.1, and this is what I get for lower and upper case DGESV:
...
For my (optimised) BLAS library I get :

A shown below, GotoBLAS contains upper and lowercase symbols as shown below. I suspect this was done to give programmers flexibility in the names i.e. upper or lower case. (Note: the grep -i flag does ignores case):

$ nm GotoBLAS.lib | grep -i dgesv
00000000 T _DGESV
00000000 I __imp__DGESV
00000000 I __imp__dgesv
00000000 T _dgesv
00000000 I __imp__dgesv_
00000000 T _dgesv_

If you take a look at the BLAS page, you will see that DGESV is not listed as subroutine BLAS. Nevertheless, some BLAS libraries implement a few LAPACK subroutines (DGESV in this case) -- I suspect because their developers believe they can do a better job. It is perhaps the case that such subroutines will outperform the LAPACK equivalents.

I wasn't able to find the default/reference BLAS library; I thought there was a ...blas.lib file somewhere that I could then add to the additional dependencies in Visual Studio. I only found the blas.lib and blasd.lib files in the Lapack_3.1.1\lib\win32 folder. However, corresponding to the Cygwin nm command, these two libraries do not include any dgesv or DGESV routine!? I will rebuild my gotoBLAS implementation and see what happens.

As explained above, DGESV is not a BLAS routine, and that's why the reference BLAS does not name or implement it.

Compiling GotoBLAS does not require paths to sources or libraries of LAPACK or the reference BLAS.

[graphicsRat]

I tried to rebuild the Blas library, following the exact same procedure as before. But when trying to build the .dll and .lib by executing "make dll" within the VS command prompt, I first receive this message:
.gensymbol win2k dummy 0 X86 > libgoto_core2-r1.26.def
/bin/sh: ./gensymbol: /usr/bin/perl: bad interpreter: No such file or directory
make: *** [libgoto_core2-r1.26.def] Error 126

During the execution of "make dll" for the first time, it seems that the definition file libgoto_core2-r1.26.def is generated, thus when typing "make dll" for the second time, now there is a different error message:
[...]
dlltool: Syntax error in def file libgoto_core2-r1.26.def:0
dlltool: Syntax error in def file libgoto_core2-r1.26.def:0
lib /machine:i386 /def:libgoto_core2-r1.26.def
Microsoft <R> LIbrary Manager [...]

Bibliothek "libgoto_core2-r1.26.lib" und Objekt "libgoto_core2-r1.26.exp" werden erstellt.


I did everything as before, and I receive those syntax errors in the definition file!? I saw that I had the same two "Syntax error" messages before (see one of my posts above), with the difference that back then I was missing the path to the lib.exe, thus I didn't care so much about the two syntax errors!?

Its hard to understand what stage you're having problems with. The compilation of the library (into a *.a file) in Cygwin? or the making of the *.dll and *.lib file in VS command prompt? Also, I thought you'd successfully compiled the library into a dll? Did you download the source twice into two directories and try compiling them using two different techniques?

Anyway, I recommend that you type "make clean" in the VS command prompt, in order to get rid of the output of the previous compile before typing "make dll". ("make clean" should also work in the first, Cygwin, phase. However, this may not be necessary, as you will have to compile GotoBLAS from scratch, and you know how long that takes ;-) .)

A .dll and a .lib file are built, but they are very small and the "nm" command shows me, that they are practically empty

That's odd. Repeat the second phase, i.e. "make clean" followed by "make dll" and lets know what happens.

I am close to giving up, but I need this solver so badly... I hope you are not giving up yet!?

I've felt close to giving up myself, but I just kept trying. You may have read my post last week where I sought help with a number of serious problems I had with some subroutines. I have now solved the problem, but it took a bit of effort. At the end of the day, the problems were due to mistakes I made in my code.

Warning: rant ahead
If you are solving huge, dense (i.e. non-sparse) linear systems like I am, there's nothing else out there but LAPACK. Not even Matlab will do, because its not optimized for any machine, and it is for this reason that Matlab will take forever to solve linear systems that LAPACK (with a good BLAS) will solve in seconds or a few mins. BTW, did you know that Matlab started out as an interface to LINPACK and EISPACK, both of which were superseded by LAPACK? (read paragraph 1 of the LAPACK Wikipedia article). Matlab today still relies on LAPACK for its linear solvers, as does the GNU Scientific Library (GSL). This weekend in a fit of desperation, I tried using GSL for the second time, and like before, I gave up because it took forever (I'm sure you know why).

The point I'm trying to make is that, just as UNIX has won the battle for the design of OS' (very few people do OS' differently), the battle for linear solvers is pretty much over. There there is nothing else out there. Just LAPACK, interfaces to LAPACK and the different flavors of LAPACK :-) .

[jocheno]

Hey there -

Thanks for giving me back my motivation with that last paragraph. It definitely seems to be worth the effort! But back to the problem(s)

I did not experience a problem when compiling the library (into an *.a file) in Cygwin. That works just fine.

The problems appeared when doing the "make dll" in the gotoBLAS/exports folder within the VS prompt. I had used all possible combinations in using "make clean", in Cygwin, in the VS prompt... STRANGELY, just now I tried "make dll" in the VS prompt again, and it works!? I really start doubting that I am dealing with a deterministic system here ;-) Anyway.

I copied the new libgoto_core2-r1.26.dll file from the gotoBLAS\exports folder into the windows\system32 folder, opened my VS lapack test project again, compiled it successfully and executed the lapak_test.exe file in the Debug folder of that project. I GET THE SAME ERROR AS BEFORE (see my post from Thu Aug 20, 2009 12:44 pm).

I checked the libgoto_core2-r1.26.lib file with the cygwin "nm ... | grep DGESV" command and got exactly what you are getting on your laptop. Except: you were performing the nm command on the libGotoBLAS.lib file instead of an optimised library file that should look like libgoto_<processortype>-<number>.lib!? Is "libGotoBLAS.lib" the reference/standard/non-optimised BLAS library? I would like to try to run my program with that library, but I don't have it and I can't find it anywhere!? Does it make any sense if you sent me that file?

Take care,

Jochen

[graphicsRat]

I checked the libgoto_core2-r1.26.lib file with the cygwin "nm ... | grep DGESV" command and got exactly what you are getting on your laptop. Except: you were performing the nm command on the libGotoBLAS.lib file instead of an optimised library file that should look like libgoto_<processortype>-<number>.lib!? Is "libGotoBLAS.lib" the reference/standard/non-optimised BLAS library? I would like to try to run my program with that library, but I don't have it and I can't find it anywhere!? Does it make any sense if you sent me that file?

The name libGotoBLAS that I used is a hard link to the actual gotoBLAS library compiled for my machine. I create this link because I use two computers, one at home and the another at the office, and the gotoBLAS lib files for both machines have different names.

I think you should use the reference BLAS for now in order to debug your project settings. The reference BLAS works on all machines. If it doesn't, theres almost definitely something wrong with your project settings.