[CMake] Extension proposal: CheckFortranFuinctionExists.cmake

[Alan W. Irwin]

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.

>
> 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.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________