Bernd Schubert wrote:
From my experience a huge problem is the way in which the libs are compiled (this refers to the underscore issue mentioned by Bernd). This is currently not taken care of at all. In Boost's numeric bindings this is taken care of by a special macro called FORTRAN_ID. It is not straight forward to find out how the code has been compiled, but it could be done by trial and error. If e.g. the linking in my example from the previous mail fails it may be due to two reasons, either the libs are missing or they have been compiled including a leading underscore. Well, maybe even more flavors exist.On Wednesday 25 June 2008, Alan W. Irwin wrote:I think that assumption needs lots of qualifiers. Did your run-time actually give correct numerical results when linking from a C main programme to f77blas.lib? Interfacing C/C++ and Fortran is a tricky business. There is a project called cfortran that tries to do it for all the different Unix variants, but it is pretty complicated because of various naming conventions on each brand of Unix. Because of those complications, systems often have both C and Fortran versions of BLAS installed. For example, it appears your system has cblas.lib which is the library I think you want to link to from C/C++ code.No, it is really no problem to link fortran libraries and to call their functions. It is onkly a bit nasty sometimes to write the proto types of the blas/lapack functions, since nobody seems to have created a complete set of these, afaik. For real number crunching one also uses the intel/amd or goto libraries and there is always only one library of these, for both C and Fortran (afaik, these optimized libraries are also not written in fortran anymore, they just have this stupid interface to be compatible with fortran. The other issue with fortran libraries is to figure out, how these have been compiled (additional underscores, etc).On the other hand, cblas even has a slightly different interface than nativ blas, so without changing the existing code it is not suitable for linking. Regarding the compatibility, I tried out and verified quite a few of the functions offered via CBLAS and LAPACK mainly via http://boost-sandbox.cvs.sourceforge.net/boost-sandbox/boost-sandbox/boost/numeric/bindings/ . Unfortunately I did not build the libraries I am currently working with myself so I can not give detailed information about how they were built but my unit tests yielded correct results. >From another Fortran library (Dierckx Fitpack) which I built myself from within the Cygwin environment (g77 -fno-underscoring -mno-cygwin -O3 -c *.f followed by lib *.o /out:fitpack.lib), I can say that, at least in the way I build the libs, it is absolutely possible to use the functions and get correct results. Obviously this requires some work by the user, again because of the missing proxies. Row vs. column major storage is from what I know also something one has to take care of. Regarding the last comment of Bernd, regarding different interfaces of CBLAS and native BLAS, I have no clue - but if that is true, isn't it then dangerous to check at first for the "cblas;f77blas;atlas" (FindBLAS.cmake lines 88-97) libraries and then for "sgemm;dgemm;blas" (FindBLAS.cmake lines 100-107), etc. ?? Finally I want to emphasize that the effort that has been done in creating the FindBLAS package is highly appreciated and that I am not at all a Fortran specialist. I just have little experience with mixing Fortran and C/C++ and so far I seem to have been lucky. There may be (and unfortunately probably are) some issues I am not aware of. - Hauke -- Tim Hauke Heibel Computer Aided Medical Procedures (CAMP) fon: +49 89 289 19427 fax: +49 89 289 17059 |
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
