[CMake] Extension proposal: CheckFortranFuinctionExists.cmake

[Bernd Schubert]

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