On Wednesday 25 June 2008, Alan W. Irwin wrote: > On 2008-06-25 16:32+0200 Bernd Schubert wrote: > > On Wednesday 25 June 2008, Alan W. Irwin wrote: > >> On 2008-06-25 15:15+0200 Hauke Heibel wrote: > >>> Hi there, > >>> > >>> I started diving into the world of CMake and spend the last two days in > >>> trying to convert a project of mine to be working with CMake. > >>> > >>> We are using BLAS in the project, so obviously I gave > >>> FIND_PACKAGE(BLAS) a shot. In the beginning it was not really working, > >>> but I found a workaround which I would like to discuss - maybe it will > >>> be useful for others as well. > >>> > >>> So here is the scenario. I am given a machine having only access to > >>> static pre-compiled libraries of BLAS (in my case atlas.lib, cblas.lib > >>> and f77blas.lib). It would be great if the FIND_PACKAGE script would > >>> allow me to use these libraries even when I do not have a Fortran > >>> compiler at hand. Why should I need it anyways - the libs are > >>> pre-compiled. > >>> > >>> So in the first step I managed to get FindBLAS.cmake running that far, > >>> that it finds the libs but as said before, it was failing due to the > >>> missing Fortran compiler. To resolve this final issue I did the > >>> following. > >>> > >>> Since Fortran compiled libraries can be used from C/C++, why not simply > >>> create a test based on a .cpp file. I gave it a try and it seems to > >>> work: > >> > >> 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). > > You have described issues which illustrate and support my point. They may > be considered fairly trivial on one fixed platform but become important if > you are trying to make a multi-platform build system. For example, what do > you do about the underscore issue if you are testing the linking of C code > with the fortran blas library? On one platform you will have to test sgemm, > on another you will have to test sgemm_. These cross-platform build-system > issues all disappear if you test C/C++ code against the C version of blas.
Yeah, I entirely understand your point. Unfortunately using cblas is presently too troublesome. Fortunately I don't have the platform problems. All systems I have to deal with are Linux only. > > > 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. > > Changing your existing code once to link to cblas may be a smaller price to > pay. If your existing C/C++ code linked to the fortran BLAS library is to > work on multiple platforms, what do you do about the cross-platform issue > involving underscores? You will end up doing a lot of extra work to > support the platform variations that is not required if you link to the C > version of BLAS. I wish it would be that easy, but for example the ACML is presently not easily cblas compatible (and most system I do calculations on are amd-based). http://forums.amd.com/forum/messageview.cfm?catid=217&threadid=89362 Cheers, Bernd _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake