Hi everyone -
A simple (some people might say "stupid") question, which should have a really simple answer to it:
Do I need to #include clapack.h, f2c.h and blaswrap.h in my C or C++ file? If yes, why are the arguments in the subrouting definitions in clapack.h of FORTRAN data types (integer, real, complex) instead of C data types (long int, float, struct)??? Isn't the f2c suppose to do exactly this, to translate from FORTRAN to C? My compiler complains about "integer" and "real" in clapack.h...
If I do not need to #include clapack.h, f2c.h and blaswrap.h: what do I need to do to call a Clapack function like for example dgesv_? I have already included the path to the libraries (LIB) in Visual Studio!? Any other line of code or command I need to put in my C or C++ file?
Thank you so much for helping me!
Jochen
Calling Clapack functions in Visual Studio 2008 / Windows XP
36 posts
• Page 1 of 3 • 1, 2, 3
Calling Clapack functions in Visual Studio 2008 / Windows XP
by jocheno » Mon Aug 10, 2009 5:49 am
- jocheno
- Posts: 19
- Joined: Mon Aug 10, 2009 3:37 am
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by graphicsRat » Mon Aug 10, 2009 10:52 am
Hello Jochen,
Are you the one that sent me a private message? ...
I've found an easy way to use LAPACK directly (no CLAPACK needed) in all versions of Visual Studio. I was writing a HOW-TO about, but got side tracked by other stuff. I'll get back to it later today, and post bits and pieces of the instructions.
Stay tuned ;-)
- Olumide
Are you the one that sent me a private message? ...
I've found an easy way to use LAPACK directly (no CLAPACK needed) in all versions of Visual Studio. I was writing a HOW-TO about, but got side tracked by other stuff. I'll get back to it later today, and post bits and pieces of the instructions.
Stay tuned ;-)
- Olumide
- graphicsRat
- Posts: 84
- Joined: Wed Mar 25, 2009 3:08 pm
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by graphicsRat » Mon Aug 10, 2009 6:30 pm
This is the first part of a HOWTO that I'm writing on using LAPACK with Visual Studio. In doing so, I've made the assumption that the reader, although probably an expert in some other discipline that requires a linear equation solver, is a novice when it comes to LAPACK -- just as I was when I started. For this reason, I've tried to explain the whys rather than dispense instructions.
Thanks to Evgenii Rudnyi and Mark Hoemmen at http://groups.google.com/group/matrixprogramming their early suggestions and the reading the draft of this HOWTO. Any inaccuracies in this document are mine. Use with care.
Soon to follow, part 2: Using LAPACK subroutines in a Visual (Studio) C/C++ Project
###########################################
Part 1: Compiling GotoBLAS
(Cygwin required -- http://cygwin.org/ )
###########################################
Preamble
LAPACK [http://www.netlib.org/lapack/] is designed as a two-tiered Fortran library, comprising higher level subroutines and "lower-level Basic Linear Algebra Subprograms (BLAS) in order to effectively exploit the caches on modern cache-based architectures" [http://en.wikipedia.org/wiki/LAPACK]. For reference purposes, the LAPACK installation provides a(n untuned) version of the BLAS which is not optimized for any architecture. This reference BLAS implementation may be orders of magnitude slower than optimized implementations, for matrix factorizations and other computationally intensive matrix operations. Optimized implementations the BLAS are available from a number of vendors and projects such as: Intel (commercial), AMD, and ATLAS, but my favorite is GotoBLAS because it is:
- currently the fastest BLAS implementation
[see research report "Choosing the optimal BLAS and LAPACK library" at http://tinyurl.com/m6lmqs ]
- trivial to compile
- is free (available without cost) for research/academic use.
You can read about sole author of this library Kazushige Goto (pronounced "Goat toe") at http://en.wikipedia.org/wiki/Kazushige_Goto
[Links to other BLAS implementations]
MKL - http://software.intel.com/en-us/intel-mkl/
AMD (AMCL) -- http://developer.amd.com/cpu/Libraries/ ... fault.aspx
ATLAS -- http://math-atlas.sourceforge.net/ (I was unable to build this library. I found the instructions too lengthy, complicated, and often ambiguous. Nevertheless, the goal of the ATLAS project is an admirable one. It aims to, by self-discovery, automatically generate an optimized BLAS library. However, its performance trails that of other libraries http://en.wikipedia.org/wiki/Automatica ... a_Software )
Compiling GotoBLAS
The GotoBLAS source is available from http://www.tacc.utexas.edu/resources/software/#blas (there's short registration
form to fill), and can be compiled for Windows with Cygwin. No changes need to be made to GotoBLAS' config file
Makefile.rule, unless a particular compiler is preferred. Happily, the config file automatically enables multithreading if more than one processor is available.
1. Download and extract the GotoBLAS source to any directory of choice, and make any desired changes to the config file (the default option should also work well).
2. In Cygwin, "cd" to the top-level directory containing the source, and type "make"
3. The result of this process should be a file libgoto_<processor_class>-r<a_number>.a, and a (symbolic) link libgoto.a pointing to this file. (For example, libgoto_banias-r1.26.a, or libgoto_northwood-r1.26.a)
4. Now for the final part, building a Windows library (*.lib) and dll for GotoBLAS. This is best done 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 the locations of all the Visual Studio tools e.g. compiler, linker.
- Add the path to the Cygwin binaries to your Windows PATH variable. (On my machine, this path is C:\cygwin\bin).
(Refer to the section "Adding or Editing Environment Variables" of the following page http://vlaurie.com/computers2/Articles/environment.htm for help on how to do this.)
- Launch the Visual Studio command prompt from:
Start Menu -> Programs -> Microsoft Visual Studio -> Visual Studio Tools -> Visual Studio Command prompt
- In the Visual Studio command prompt, change directory to the "exports" subdirectory of GotoBLAS and run the command "make dll". The result should be something like: libgoto_<processor_class>-r<a_number>.lib and libgoto_<processor_class>-r<a_number>.dll . For example: libgoto_banias-r1.26.dll, or libgoto_northwood-r1.26.dll
Final note:
* Windows needs to be told where to find this dll, else you will get a serious error when you try to run your program. There are several ways to do accomplish this. One, is to add the location of the dll to the PATH environment variable. Another is to simply copy the dll to the Windows\system32 folder. I did the later.
For more information, refer to Microsoft guidelines on Search Path Used by Windows to Locate a DLL
Thanks to Evgenii Rudnyi and Mark Hoemmen at http://groups.google.com/group/matrixprogramming their early suggestions and the reading the draft of this HOWTO. Any inaccuracies in this document are mine. Use with care.
Soon to follow, part 2: Using LAPACK subroutines in a Visual (Studio) C/C++ Project
###########################################
Part 1: Compiling GotoBLAS
(Cygwin required -- http://cygwin.org/ )
###########################################
Preamble
LAPACK [http://www.netlib.org/lapack/] is designed as a two-tiered Fortran library, comprising higher level subroutines and "lower-level Basic Linear Algebra Subprograms (BLAS) in order to effectively exploit the caches on modern cache-based architectures" [http://en.wikipedia.org/wiki/LAPACK]. For reference purposes, the LAPACK installation provides a(n untuned) version of the BLAS which is not optimized for any architecture. This reference BLAS implementation may be orders of magnitude slower than optimized implementations, for matrix factorizations and other computationally intensive matrix operations. Optimized implementations the BLAS are available from a number of vendors and projects such as: Intel (commercial), AMD, and ATLAS, but my favorite is GotoBLAS because it is:
- currently the fastest BLAS implementation
[see research report "Choosing the optimal BLAS and LAPACK library" at http://tinyurl.com/m6lmqs ]
- trivial to compile
- is free (available without cost) for research/academic use.
You can read about sole author of this library Kazushige Goto (pronounced "Goat toe") at http://en.wikipedia.org/wiki/Kazushige_Goto
[Links to other BLAS implementations]
MKL - http://software.intel.com/en-us/intel-mkl/
AMD (AMCL) -- http://developer.amd.com/cpu/Libraries/ ... fault.aspx
ATLAS -- http://math-atlas.sourceforge.net/ (I was unable to build this library. I found the instructions too lengthy, complicated, and often ambiguous. Nevertheless, the goal of the ATLAS project is an admirable one. It aims to, by self-discovery, automatically generate an optimized BLAS library. However, its performance trails that of other libraries http://en.wikipedia.org/wiki/Automatica ... a_Software )
Compiling GotoBLAS
The GotoBLAS source is available from http://www.tacc.utexas.edu/resources/software/#blas (there's short registration
form to fill), and can be compiled for Windows with Cygwin. No changes need to be made to GotoBLAS' config file
Makefile.rule, unless a particular compiler is preferred. Happily, the config file automatically enables multithreading if more than one processor is available.
1. Download and extract the GotoBLAS source to any directory of choice, and make any desired changes to the config file (the default option should also work well).
2. In Cygwin, "cd" to the top-level directory containing the source, and type "make"
3. The result of this process should be a file libgoto_<processor_class>-r<a_number>.a, and a (symbolic) link libgoto.a pointing to this file. (For example, libgoto_banias-r1.26.a, or libgoto_northwood-r1.26.a)
4. Now for the final part, building a Windows library (*.lib) and dll for GotoBLAS. This is best done 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 the locations of all the Visual Studio tools e.g. compiler, linker.
- Add the path to the Cygwin binaries to your Windows PATH variable. (On my machine, this path is C:\cygwin\bin).
(Refer to the section "Adding or Editing Environment Variables" of the following page http://vlaurie.com/computers2/Articles/environment.htm for help on how to do this.)
- Launch the Visual Studio command prompt from:
Start Menu -> Programs -> Microsoft Visual Studio -> Visual Studio Tools -> Visual Studio Command prompt
- In the Visual Studio command prompt, change directory to the "exports" subdirectory of GotoBLAS and run the command "make dll". The result should be something like: libgoto_<processor_class>-r<a_number>.lib and libgoto_<processor_class>-r<a_number>.dll . For example: libgoto_banias-r1.26.dll, or libgoto_northwood-r1.26.dll
Final note:
* Windows needs to be told where to find this dll, else you will get a serious error when you try to run your program. There are several ways to do accomplish this. One, is to add the location of the dll to the PATH environment variable. Another is to simply copy the dll to the Windows\system32 folder. I did the later.
For more information, refer to Microsoft guidelines on Search Path Used by Windows to Locate a DLL
Last edited by graphicsRat on Fri Aug 14, 2009 11:31 am, edited 6 times in total.
- graphicsRat
- Posts: 84
- Joined: Wed Mar 25, 2009 3:08 pm
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by graphicsRat » Mon Aug 10, 2009 7:27 pm
###########################################
Using LAPACK subroutines in a Visual (Studio) C/C++ Project -- Part 1
###########################################
1. Download the LAPACK source or precompiled binaries from http://icl.cs.utk.edu/lapack-for-windows/ . Sources have been and can be can be compiled into debug and release versions. File names of the precomputed debug libraries end with the letter "d" e.g. BLASd.lib and lapackd.lib (in comparison to the release versions BLAS.lib and lapack.lib).
2. If you chose to compile LAPACK, you will require a Fortran compiler and libraries. I recommend the Intel Fortran compiler (distributed with libraries) [http://software.intel.com/en-us/articles/intel-software-evaluation-center/].
3. Obtain a tuned version of BLAS for your machine (refer to "Compiling GotoBLAS").
4. Create an empty Visual Studio console application project, and add the following sample C program to it:
http://www.cs.rochester.edu/~bh/cs400/using_lapack.html
5. rename the prototypes in the above program to
void dgesv_( )
void dgels_( )
to
extern "C" void dgesv_( )
extern "C" void dgels_( )
6. Add the following libraries to the Visual Studio project settings, under Linker -> Input -> Additional Dependencies. For example, on my laptop:
libgoto_banias-r1.26.lib
lapack.lib
Note: because BLAS libraries commonly provide faster versions of some LAPACK subroutines, the BLAS library must be listed before before LAPACK library.
Note: the make sure that the gotoBLAS dll is on your system path e.g. in the WINDOWS\system32 folder, else binary won't run.
7. Compile the project and run the resulting executable. You should get the output:
The solution is -0.661082 9.456125 -16.014625
Prologue:
Part 2 of this HOWTO will briefly explain what "dgesv" means and how to call it and other LAPACK subroutines with the appropriate arguments.
Using LAPACK subroutines in a Visual (Studio) C/C++ Project -- Part 1
###########################################
1. Download the LAPACK source or precompiled binaries from http://icl.cs.utk.edu/lapack-for-windows/ . Sources have been and can be can be compiled into debug and release versions. File names of the precomputed debug libraries end with the letter "d" e.g. BLASd.lib and lapackd.lib (in comparison to the release versions BLAS.lib and lapack.lib).
2. If you chose to compile LAPACK, you will require a Fortran compiler and libraries. I recommend the Intel Fortran compiler (distributed with libraries) [http://software.intel.com/en-us/articles/intel-software-evaluation-center/].
3. Obtain a tuned version of BLAS for your machine (refer to "Compiling GotoBLAS").
4. Create an empty Visual Studio console application project, and add the following sample C program to it:
http://www.cs.rochester.edu/~bh/cs400/using_lapack.html
5. rename the prototypes in the above program to
void dgesv_( )
void dgels_( )
to
extern "C" void dgesv_( )
extern "C" void dgels_( )
6. Add the following libraries to the Visual Studio project settings, under Linker -> Input -> Additional Dependencies. For example, on my laptop:
libgoto_banias-r1.26.lib
lapack.lib
Note: because BLAS libraries commonly provide faster versions of some LAPACK subroutines, the BLAS library must be listed before before LAPACK library.
Note: the make sure that the gotoBLAS dll is on your system path e.g. in the WINDOWS\system32 folder, else binary won't run.
7. Compile the project and run the resulting executable. You should get the output:
The solution is -0.661082 9.456125 -16.014625
Prologue:
Part 2 of this HOWTO will briefly explain what "dgesv" means and how to call it and other LAPACK subroutines with the appropriate arguments.
Last edited by graphicsRat on Fri Aug 14, 2009 11:35 am, edited 2 times in total.
- graphicsRat
- Posts: 84
- Joined: Wed Mar 25, 2009 3:08 pm
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by graphicsRat » Mon Aug 10, 2009 8:27 pm
###########################################
Using LAPACK subroutines in a Visual (Studio) C/C++ Project -- Part 2
###########################################
(Note: this is the first draft of this section.)
In the previous section, I explained how to call a LAPACK subroutine e.g. dgesv_ from a C or C++ program, but I did not explain what the dgesv meant as well as its arguments. This is the purpose of this part of the HOWTO. In doing so, I will refer to the LAPACK documentation and hopefully show how easy it is to find an appropriate LAPACK subroutine and create the corresponding C/C++ function prototype for it.
Understanding dgesv
Prefix -- "dge"
From the LAPACK naming scheme -- http://www.netlib.org/lapack/lug/node24.html, it is plain to see that:
- d in "dgesv" means: double precsion data
- ge in "dgesv" means: general as in unsymmetric matrix
As such we can deduce that "dge" refers to the sort of matrix we have -- a general/unymmetric matrix containing double precision data
Suffix -- "sv"
This refers to the type of driver routine (solver in lay speak) to be used to solve the linear system. There are two kinds on drivers: simple drivers (suffixed with "sv") and "expert" drivers (suffixed with "svx"). Refer to http://www.netlib.org/lapack/lug/node26.html .
Therefore dgesv is simple driver routine for a general/unymmetric matrix containing double precision data.
Subroutine arguments
From the page http://www.netlib.org/lapack/double/dgesv.f , we can see that the subroutine dgesv has 8 arguments.
- The first argument is N, an integer. This is marked as an input (meaning argument will not be modified, as opposed to an input argument or an input/output argument) in the documentation. In C/C++ speak we can therefore refer to argument 1 as a constant integer i.e. "const int". However, because in Fortran all ALL arguments, *without exception* are passed by address, the type of N in C/C++ is: const *int . (Same goes for argument 2.)
- Argument 3, marked in the documentation as an input/output double precision array. In C/C++ terms input/output means NOT-constant. Therefore, because arguments are passed by reference, the type of argument 3 is: double * .
- Argument 5, marked in the documentation as an output integer array. In C/C++ terms this means the argument is not a const. Therefore argument 5 is of type int* . Same goes for argument 8, even though the argument is not an array (remember, all Fortran arguments are passed by address).
It should now be clear why the C/C++ prototype for dgesv is
Prologue:
A pattern for using directly LAPACK subroutines should now be clear.
- First find the appropriate subroutine from the list of available drivers http://www.netlib.org/lapack/lug/node25.html .
- Look up the driver in the index of routines http://www.netlib.org/lapack/explore-html/
- Create a the appropriate C/C++ prototype for the driver.
Enjoy.
(Next, using CLAPACK in Visual Studio)
Using LAPACK subroutines in a Visual (Studio) C/C++ Project -- Part 2
###########################################
(Note: this is the first draft of this section.)
In the previous section, I explained how to call a LAPACK subroutine e.g. dgesv_ from a C or C++ program, but I did not explain what the dgesv meant as well as its arguments. This is the purpose of this part of the HOWTO. In doing so, I will refer to the LAPACK documentation and hopefully show how easy it is to find an appropriate LAPACK subroutine and create the corresponding C/C++ function prototype for it.
Understanding dgesv
Prefix -- "dge"
From the LAPACK naming scheme -- http://www.netlib.org/lapack/lug/node24.html, it is plain to see that:
- d in "dgesv" means: double precsion data
- ge in "dgesv" means: general as in unsymmetric matrix
As such we can deduce that "dge" refers to the sort of matrix we have -- a general/unymmetric matrix containing double precision data
Suffix -- "sv"
This refers to the type of driver routine (solver in lay speak) to be used to solve the linear system. There are two kinds on drivers: simple drivers (suffixed with "sv") and "expert" drivers (suffixed with "svx"). Refer to http://www.netlib.org/lapack/lug/node26.html .
Therefore dgesv is simple driver routine for a general/unymmetric matrix containing double precision data.
Subroutine arguments
From the page http://www.netlib.org/lapack/double/dgesv.f , we can see that the subroutine dgesv has 8 arguments.
- The first argument is N, an integer. This is marked as an input (meaning argument will not be modified, as opposed to an input argument or an input/output argument) in the documentation. In C/C++ speak we can therefore refer to argument 1 as a constant integer i.e. "const int". However, because in Fortran all ALL arguments, *without exception* are passed by address, the type of N in C/C++ is: const *int . (Same goes for argument 2.)
- Argument 3, marked in the documentation as an input/output double precision array. In C/C++ terms input/output means NOT-constant. Therefore, because arguments are passed by reference, the type of argument 3 is: double * .
- Argument 5, marked in the documentation as an output integer array. In C/C++ terms this means the argument is not a const. Therefore argument 5 is of type int* . Same goes for argument 8, even though the argument is not an array (remember, all Fortran arguments are passed by address).
It should now be clear why the C/C++ prototype for dgesv is
- Code: Select all
extern "C" void dgesv_( const int * , const int * , double * , const int * , int * , double * , const int * , int * );
Prologue:
A pattern for using directly LAPACK subroutines should now be clear.
- First find the appropriate subroutine from the list of available drivers http://www.netlib.org/lapack/lug/node25.html .
- Look up the driver in the index of routines http://www.netlib.org/lapack/explore-html/
- Create a the appropriate C/C++ prototype for the driver.
Enjoy.
(Next, using CLAPACK in Visual Studio)
Last edited by graphicsRat on Tue Aug 11, 2009 12:54 am, edited 3 times in total.
- graphicsRat
- Posts: 84
- Joined: Wed Mar 25, 2009 3:08 pm
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by graphicsRat » Mon Aug 10, 2009 9:41 pm
jocheno wrote:Do I need to #include clapack.h, f2c.h and blaswrap.h in my C or C++ file? If yes, why are the arguments in the subrouting definitions in clapack.h of FORTRAN data types (integer, real, complex) instead of C data types (long int, float, struct)??? Isn't the f2c suppose to do exactly this, to translate from FORTRAN to C? My compiler complains about "integer" and "real" in clapack.h...
If I do not need to #include clapack.h, f2c.h and blaswrap.h: what do I need to do to call a Clapack function like for example dgesv_? I have already included the path to the libraries (LIB) in Visual Studio!? Any other line of code or command I need to put in my C or C++ file?
There's a simple guide to CLAPACK here http://www.netlib.org/clapack/readme
Take a look at this sample program (uses CLAPACK) http://pastebin.com/f58d84193 (note that it uses includes f2c.h and clapack.h .)
Be sure to have BLAS.lib, clapack.lib, and libf2c.lib listed your project properties -> Linker -> Input -> Additional dependencies, if you are compiling a release version. Use BLASd.lib, clapack.libd, and libf2cd.lib (*d.lib) if you are compiling debug versions.
Expected output:
- Code: Select all
DGESV [info=0]
DGESV [n=100,k=1] 1.000000s 0.333333MHz (check:7.571983e-015)
- graphicsRat
- Posts: 84
- Joined: Wed Mar 25, 2009 3:08 pm
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by jocheno » Tue Aug 11, 2009 4:05 am
Hey there!
Wow, thanks so much for the detailed instructions. I started to follow your instructions, downloaded the GotoBLAS source but in Cygwin the "make" command wasn't found. "make" ist rather a command provided by some compiler isn't it? Or is it by Cygwin?
Anyhow, I still don't quite understand how you can use LAPACK with C or C++, as it is written in Fortran!? That's why there is CLAPACK which supposedly is for people using C, isn't there!?
I therefore will go ahead with you last post, giving it another try with CLAPACK. I think I hadn't added some of the libraries as "additional dependencies" yet, I only had provided the path to the library files in Visual Studio. Why is it that you need to define additional dependencies as well?
Still: If you have another hint how to get the GotoBLAS source compiled, I would be very thankful! If that BLAS library is realy so much faster, I might want to use it with CLAPACK as well.
Cheers,
Jochen
Wow, thanks so much for the detailed instructions. I started to follow your instructions, downloaded the GotoBLAS source but in Cygwin the "make" command wasn't found. "make" ist rather a command provided by some compiler isn't it? Or is it by Cygwin?
Anyhow, I still don't quite understand how you can use LAPACK with C or C++, as it is written in Fortran!? That's why there is CLAPACK which supposedly is for people using C, isn't there!?
I therefore will go ahead with you last post, giving it another try with CLAPACK. I think I hadn't added some of the libraries as "additional dependencies" yet, I only had provided the path to the library files in Visual Studio. Why is it that you need to define additional dependencies as well?
Still: If you have another hint how to get the GotoBLAS source compiled, I would be very thankful! If that BLAS library is realy so much faster, I might want to use it with CLAPACK as well.
Cheers,
Jochen
- jocheno
- Posts: 19
- Joined: Mon Aug 10, 2009 3:37 am
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by jocheno » Tue Aug 11, 2009 4:47 am
Ok, this is what I receive as error messages (in German only, but I think it should be understandable. If not, let me know)using the code from http://pastebin.com/f58d84193. I included string.h, stdio.h, f2c.h, clapack.h and blaswrap.h and provided BLAS.lib, clapack.lib and libf2c.lib as additional dependencies in Visual Studio.
There seems to be a general problem with the two standard libraries MSVCRTD and LIBCMT!??? Anything I can do about that?
1>------ Erstellen gestartet: Projekt: Clapack_test2, Konfiguration: Debug Win32 ------
1>Kompilieren...
1>main.c
1>d:\programme\clapack-3.1.1-visualstudio\include\f2c.h(159) : warning C4005: 'min': Makro-Neudefinition
1> d:\programme\visualstudio\vc\include\stdlib.h(850): Siehe vorherige Definition von 'min'
1>d:\programme\clapack-3.1.1-visualstudio\include\f2c.h(160) : warning C4005: 'max': Makro-Neudefinition
1> d:\programme\visualstudio\vc\include\stdlib.h(849): Siehe vorherige Definition von 'max'
1>h:\eigene dateien\visual studio 2008\projects\clapack_test2\clapack_test2\main.c(30) : warning C4013: 'f2c_dcopy' undefiniert; Annahme: extern mit Rückgabetyp int
1>h:\eigene dateien\visual studio 2008\projects\clapack_test2\clapack_test2\main.c(45) : warning C4101: 'notrans': Unreferenzierte lokale Variable
1>h:\eigene dateien\visual studio 2008\projects\clapack_test2\clapack_test2\main.c(43) : warning C4101: 'rtn': Unreferenzierte lokale Variable
1>Verknüpfen...
1>LIBCMT.lib(invarg.obj) : error LNK2005: __invoke_watson ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(dosmap.obj) : error LNK2005: __errno ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(tidtable.obj) : error LNK2005: __encode_pointer ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(tidtable.obj) : error LNK2005: __decode_pointer ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: __amsg_exit ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: __initterm_e ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: _exit ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: __exit ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: __cexit ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(mlock.obj) : error LNK2005: __unlock ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(mlock.obj) : error LNK2005: __lock ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(setlocal.obj) : error LNK2005: __configthreadlocale ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(winxfltr.obj) : error LNK2005: __XcptFilter ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xi_a ist bereits in MSVCRTD.lib(cinitexe.obj) definiert.
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xi_z ist bereits in MSVCRTD.lib(cinitexe.obj) definiert.
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_a ist bereits in MSVCRTD.lib(cinitexe.obj) definiert.
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_z ist bereits in MSVCRTD.lib(cinitexe.obj) definiert.
1>LIBCMT.lib(hooks.obj) : error LNK2005: "void __cdecl terminate(void)" (?terminate@@YAXXZ) ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(winsig.obj) : error LNK2005: _signal ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0.obj) : error LNK2005: _mainCRTStartup ist bereits in MSVCRTD.lib(crtexe.obj) definiert.
1>LIBCMT.lib(errmode.obj) : error LNK2005: ___set_app_type ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(atox.obj) : error LNK2005: _atoi ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LINK : warning LNK4098: Standardbibliothek "MSVCRTD" steht in Konflikt mit anderen Bibliotheken; /NODEFAULTLIB:Bibliothek verwenden.
1>LINK : warning LNK4098: Standardbibliothek "LIBCMT" steht in Konflikt mit anderen Bibliotheken; /NODEFAULTLIB:Bibliothek verwenden.
1>H:\Eigene Dateien\Visual Studio 2008\Projects\Clapack_test2\Debug\Clapack_test2.exe : fatal error LNK1169: Mindestens ein mehrfach definiertes Symbol gefunden.
1>Das Buildprotokoll wurde unter "file://h:\Eigene Dateien\Visual Studio 2008\Projects\Clapack_test2\Clapack_test2\Debug\BuildLog.htm" gespeichert.
1>Clapack_test2 - 23 Fehler, 7 Warnung(en)
========== Erstellen: 0 erfolgreich, Fehler bei 1, 0 aktuell, 0 übersprungen ==========
There seems to be a general problem with the two standard libraries MSVCRTD and LIBCMT!??? Anything I can do about that?
1>------ Erstellen gestartet: Projekt: Clapack_test2, Konfiguration: Debug Win32 ------
1>Kompilieren...
1>main.c
1>d:\programme\clapack-3.1.1-visualstudio\include\f2c.h(159) : warning C4005: 'min': Makro-Neudefinition
1> d:\programme\visualstudio\vc\include\stdlib.h(850): Siehe vorherige Definition von 'min'
1>d:\programme\clapack-3.1.1-visualstudio\include\f2c.h(160) : warning C4005: 'max': Makro-Neudefinition
1> d:\programme\visualstudio\vc\include\stdlib.h(849): Siehe vorherige Definition von 'max'
1>h:\eigene dateien\visual studio 2008\projects\clapack_test2\clapack_test2\main.c(30) : warning C4013: 'f2c_dcopy' undefiniert; Annahme: extern mit Rückgabetyp int
1>h:\eigene dateien\visual studio 2008\projects\clapack_test2\clapack_test2\main.c(45) : warning C4101: 'notrans': Unreferenzierte lokale Variable
1>h:\eigene dateien\visual studio 2008\projects\clapack_test2\clapack_test2\main.c(43) : warning C4101: 'rtn': Unreferenzierte lokale Variable
1>Verknüpfen...
1>LIBCMT.lib(invarg.obj) : error LNK2005: __invoke_watson ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(dosmap.obj) : error LNK2005: __errno ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(tidtable.obj) : error LNK2005: __encode_pointer ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(tidtable.obj) : error LNK2005: __decode_pointer ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: __amsg_exit ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: __initterm_e ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: _exit ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: __exit ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0dat.obj) : error LNK2005: __cexit ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(mlock.obj) : error LNK2005: __unlock ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(mlock.obj) : error LNK2005: __lock ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(setlocal.obj) : error LNK2005: __configthreadlocale ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(winxfltr.obj) : error LNK2005: __XcptFilter ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xi_a ist bereits in MSVCRTD.lib(cinitexe.obj) definiert.
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xi_z ist bereits in MSVCRTD.lib(cinitexe.obj) definiert.
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_a ist bereits in MSVCRTD.lib(cinitexe.obj) definiert.
1>LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_z ist bereits in MSVCRTD.lib(cinitexe.obj) definiert.
1>LIBCMT.lib(hooks.obj) : error LNK2005: "void __cdecl terminate(void)" (?terminate@@YAXXZ) ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(winsig.obj) : error LNK2005: _signal ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(crt0.obj) : error LNK2005: _mainCRTStartup ist bereits in MSVCRTD.lib(crtexe.obj) definiert.
1>LIBCMT.lib(errmode.obj) : error LNK2005: ___set_app_type ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LIBCMT.lib(atox.obj) : error LNK2005: _atoi ist bereits in MSVCRTD.lib(MSVCR90D.dll) definiert.
1>LINK : warning LNK4098: Standardbibliothek "MSVCRTD" steht in Konflikt mit anderen Bibliotheken; /NODEFAULTLIB:Bibliothek verwenden.
1>LINK : warning LNK4098: Standardbibliothek "LIBCMT" steht in Konflikt mit anderen Bibliotheken; /NODEFAULTLIB:Bibliothek verwenden.
1>H:\Eigene Dateien\Visual Studio 2008\Projects\Clapack_test2\Debug\Clapack_test2.exe : fatal error LNK1169: Mindestens ein mehrfach definiertes Symbol gefunden.
1>Das Buildprotokoll wurde unter "file://h:\Eigene Dateien\Visual Studio 2008\Projects\Clapack_test2\Clapack_test2\Debug\BuildLog.htm" gespeichert.
1>Clapack_test2 - 23 Fehler, 7 Warnung(en)
========== Erstellen: 0 erfolgreich, Fehler bei 1, 0 aktuell, 0 übersprungen ==========
- jocheno
- Posts: 19
- Joined: Mon Aug 10, 2009 3:37 am
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by graphicsRat » Tue Aug 11, 2009 9:20 am
jocheno wrote:Wow, thanks so much for the detailed instructions. I started to follow your instructions, downloaded the GotoBLAS source but in Cygwin the "make" command wasn't found. "make" ist rather a command provided by some compiler isn't it? Or is it by Cygwin?
Make is a standard UNIX/Linux utility. It you don't have it update your installation of Cygwin. I hope you know how to do that. (The default Cygwin installation does not install the entire package and may have not include make -- I would be surprised if Cygwin does not.)
jocheno wrote:Anyhow, I still don't quite understand how you can use LAPACK with C or C++, as it is written in Fortran!? That's why there is CLAPACK which supposedly is for people using C, isn't there!?
Good question. I used to wonder about this too. The answer is simple: libraries (*.lib or *.dll ) are an operating system file format, and do not retain any in formation about the language they were originally written in. As such, they can be linked with any object file (*.obj) compiled from anther language. The important thing to note is that compilers translate source files into object files, which are also language-agnostic. This means that an object file and an external library, can be linked regardless of the language they were originally written in and compiled from.
jocheno wrote:I therefore will go ahead with you last post, giving it another try with CLAPACK. I think I hadn't added some of the libraries as "additional dependencies" yet, I only had provided the path to the library files in Visual Studio. Why is it that you need to define additional dependencies as well?
Specifying paths to libraries is not sufficient because there is often more than one library in a path location. You need to inform the linker which libraries in the path you want it to link the object file(s) with.
jocheno wrote:Still: If you have another hint how to get the GotoBLAS source compiled, I would be very thankful! If that BLAS library is realy so much faster, I might want to use it with CLAPACK as well.
Optimized BLAS' may be used with any variant of LAPACK. As I explained, the reference BLAS is too slow for most applications. Let me know if you have any specific difficulty compiling GotoBLAS. I have compiled it on two machines and on both occasions it worked like a charm. The compilation does take a long time tho'. I hope you realize that each GotoBLAS compilation is optimized for the host system and should not be reused for any other machine/processor.
One last detail/tip for the aware. CLAPACK was automatically translated from Fortran to C using f2c. As such it may (don't quote me) be slower than the original LAPACK because compilers (f2c in this case) do not always generate the best code (it would be nice to see some timing tests). However, f2c has been around for along time, and like the older Fortran compilers has probably been "optimized to death". Another way to look as things is that, good or bad, at some point, a compiler will be involved in whatever you do :-) .
PS: I'll reply your other post later (I understand a bit of German :-) )
Last edited by graphicsRat on Wed Aug 12, 2009 10:45 am, edited 3 times in total.
- graphicsRat
- Posts: 84
- Joined: Wed Mar 25, 2009 3:08 pm
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by graphicsRat » Tue Aug 11, 2009 9:23 am
jocheno wrote:Ok, this is what I receive as error messages (in German only, but I think it should be understandable. If not, let me know)using the code from http://pastebin.com/f58d84193. I included string.h, stdio.h, f2c.h, clapack.h and blaswrap.h and provided BLAS.lib, clapack.lib and libf2c.lib as additional dependencies in Visual Studio.
There seems to be a general problem with the two standard libraries MSVCRTD and LIBCMT!??? Anything I can do about that?
Try ignore LIBCMT(.lib --see linker settings).
- graphicsRat
- Posts: 84
- Joined: Wed Mar 25, 2009 3:08 pm
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by jocheno » Wed Aug 12, 2009 4:48 am
First: Compilation was successfull and the .exe gives me a window that shows exactly what it was supposed to! Thank you!
Second: Double thanks for the answers to my questions. It's always great to learn things in a field that is new to you. In the beginning you can always learn fast (if you have a good teacher).
So the final thing to do before I can acutally start working on the (engineering type) problem I have, is to compile the GotoBLAS and to use LAPACK instead of CLAPACK.
Talk to you later!
Jochen
Second: Double thanks for the answers to my questions. It's always great to learn things in a field that is new to you. In the beginning you can always learn fast (if you have a good teacher).
So the final thing to do before I can acutally start working on the (engineering type) problem I have, is to compile the GotoBLAS and to use LAPACK instead of CLAPACK.
Talk to you later!
Jochen
- jocheno
- Posts: 19
- Joined: Mon Aug 10, 2009 3:37 am
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by jocheno » Wed Aug 12, 2009 6:12 am
Do you by chance know in what category I find the make package during the Cygwin installation? I don't want to install everything and the manual inclusion of make.exe doesn't seem to work (https://developer.mozilla.org/en/Windows_build_prerequisites_using_cygwin#make)???
Cheers,
Jochen
Cheers,
Jochen
- jocheno
- Posts: 19
- Joined: Mon Aug 10, 2009 3:37 am
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by sven » Wed Aug 12, 2009 10:09 am
Dear Jochen,
make is in the 'devel' category of cygwin. The cygwin setup also has a search facility where you can insert the word make.
Best wishes,
Sven.
make is in the 'devel' category of cygwin. The cygwin setup also has a search facility where you can insert the word make.
Best wishes,
Sven.
- sven
- Posts: 146
- Joined: Wed Dec 22, 2004 4:28 am
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by graphicsRat » Wed Aug 12, 2009 10:43 am
jocheno wrote:First: Compilation was successfull and the .exe gives me a window that shows exactly what it was supposed to! Thank you!
'Glad to hear that.
jocheno wrote:So the final thing to do before I can acutally start working on the (engineering type) problem I have, is to compile the GotoBLAS and to use LAPACK instead of CLAPACK.
Let me know if GotoBLAS compiles. It would help validate the HOWTO, especially step 4 which I'm pretty sure is not necessary. Its been many moons since I last built GotoBLAS.
- graphicsRat
- Posts: 84
- Joined: Wed Mar 25, 2009 3:08 pm
Re: Calling Clapack functions in Visual Studio 2008 / Windows XP
by jocheno » Thu Aug 13, 2009 2:21 am
The building of GotoBLAS finally worked after I had installed the "make" and the "gcc" packages during Cygwin setup.
Following the rest of your instructions, I had to learn that running a batch-file in cygwin requires the command "cmd /c vcvars32.bat" which then worked fine!
Running the "make dll" command in the exports directory of GotoBLAS lead to an error (126 - bad interpreter] so I went back to step 4, renaming the .a-files to .lib.
Rexecuting the "make dll" command in the exports subdirectory of GotoBLAS then lead to the following error:
"make: *** No rule to make target '../libgoto_core2-r1.26.a', needed by 'libgoto_core2-r1.26.dll'. Stop."
So I went back and re-renamed the two files "ibgoto_core2-r1.26.lib" and (symbolic link) "libgoto.lib" to .a files once more. Running "make dll" in the exports directory then produces this:
[...]
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
make: lib: Command not found
make: *** [libgoto_core2-r1.26.dll] Error 127
So finally I do have a .dll in the exports folder but no .lib!? Looking at the last error message, I assume that there is a lib command for cygwin that I am missing. So as you guys are probably still asleep (it's 8:30 a.m. in Germany), I will go ahead and try to figure something out.
Talk to you later,
Jochen
Following the rest of your instructions, I had to learn that running a batch-file in cygwin requires the command "cmd /c vcvars32.bat" which then worked fine!
Running the "make dll" command in the exports directory of GotoBLAS lead to an error (126 - bad interpreter] so I went back to step 4, renaming the .a-files to .lib.
Rexecuting the "make dll" command in the exports subdirectory of GotoBLAS then lead to the following error:
"make: *** No rule to make target '../libgoto_core2-r1.26.a', needed by 'libgoto_core2-r1.26.dll'. Stop."
So I went back and re-renamed the two files "ibgoto_core2-r1.26.lib" and (symbolic link) "libgoto.lib" to .a files once more. Running "make dll" in the exports directory then produces this:
[...]
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
make: lib: Command not found
make: *** [libgoto_core2-r1.26.dll] Error 127
So finally I do have a .dll in the exports folder but no .lib!? Looking at the last error message, I assume that there is a lib command for cygwin that I am missing. So as you guys are probably still asleep (it's 8:30 a.m. in Germany), I will go ahead and try to figure something out.
Talk to you later,
Jochen
- jocheno
- Posts: 19
- Joined: Mon Aug 10, 2009 3:37 am
36 posts
• Page 1 of 3 • 1, 2, 3
Who is online
Users browsing this forum: No registered users and 1 guest
