[CMake] FindLAPACK/FindBLAS require Fortran compiler. Why?

[Michael Wild]

On 7. Jul, 2009, at 12:35, Marcel Loose wrote:

> On Tue, 2009-07-07 at 11:19 +0200, Michael Wild wrote:
>> On 7. Jul, 2009, at 11:08, Marcel Loose wrote:
>>
>> [fixed quoting]
>>
>>> On Tue, 2009-07-07 at 10:32 +0200, Michael Wild wrote:
>>>> On 7. Jul, 2009, at 10:11, Marcel Loose wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I noticed that FindLAPACK and FindBLAS require that you enable
>>>>> Fortran
>>>>> as language, which causes CMake to check for a working Fortran
>>>>> compiler.
>>>>> IMHO, you only need the fortran runtime libraries, cause you're  
>>>>> only
>>>>> linking against the Lapack/Blas libraries. Most Linux distro's  
>>>>> have
>>>>> separate packages for compiler and runtime libraries.
>>>>>
>>>>> Is there a good reason for FindLAPACK and FindBLAS to require a
>>>>> working
>>>>> Fortran compiler?
>>>>>
>>>>> Best regards,
>>>>> Marcel Loose.
>>>>>
>>>>
>>>> That's probably because these modules ONLY search for the Fortran
>>>> interfaces. Usually one needs a different set of libraries for  
>>>> cblas
>>>> and clapack. Also the function names to check for are different  
>>>> (e.g.
>>>> cblas_dgemm versus dgemm).
>>>>
>>>> Perhaps someone finds the time to write FindCBLAS.cmake and
>>>> FindCLAPACK.cmake... But honestly, if you look at FindBLAS.cmake,
>>>> that
>>>> is quite tough as the various vendor implementations differ  
>>>> strongly
>>>> in library names, required compiler flags etc. Linking against  
>>>> Intel
>>>> MKL is just a night-mare!
>>>>
>>>> I hope this explains it a bit (although the answer is probably not
>>>> very satisfying).
>>>>
>>>> Michael
>>>>
>>>
>>> Hi Michael,
>>>
>>> I'm not surprised that it's quite difficult to make checks for
>>> Lapack/Blas work cross-platform and cross-vendor.
>>>
>>> But the essence of my question was: why do I need a Fortran  
>>> compiler!?
>>>
>>> As you wrote in your answer: That's probably because these modules
>>> ONLY
>>> search for the Fortran interfaces. Now, that's exactly what they
>>> should
>>> do: search for interfaces! Interfaces: that's libraries in the  
>>> case of
>>> Fortran. No compiler is required IMHO, cause I'm only linking  
>>> against
>>> (Fortran) libraries.
>>>
>>> Best regards,
>>> Marcel Loose.
>>
>>
>> Problem is, it is going to be difficult to check a Fortran interface
>> with a C-compiler. Sometimes the names are all upper case, sometimes
>> all lower case, sometimes there's a trailing underscore at the end of
>> all symbols, sometimes even two if the name already contains an
>> underscore. All of this makes writing a check_function_exists macro
>> quite involved.
>>
>> An yes, a compiler IS required. How else do you propose to check an
>> interface? You could use "nm" on UNIX platforms and "DUMPBIN.exe" on
>> Windows, but then you're not sure that the code is going to link
>> successfully because there might be an incompatibility of name-
>> mangling schemes between compiler, linker and library.
>>
>> This is exactly one of the reasons why there is CBLAS and CLAPACK.
>> Firstly they have interfaces suitable to C-languages, do not require
>> the user to provide work-arrays, and all name-mangling issues have
>> already been dealt with.
>>
>> Cheers
>>
>> Michael
>
> Hi Michael,
>
> I partially agree with you. The situation I'm in is that I have some  
> C++
> code that uses Lapack (through CPPLapack). These sources are compiled
> and linked using a C++ compiler. At link time I only need to link
> against the Lapack and Blas libraries. On most of these systems  
> there's
> no Fortran compiler installed, though the Fortran runtime libraries  
> are.

>
> So, I was hoping I could use FindLAPACK and FindBLAS, instead of  
> rolling
> my own. But I can't, because these macros require a Fortran library.
>

Yes, that does seem to be a use-case. Although I find it rather  
strange that cpplapack requires the Fortran interfaces... However, I  
don't see any short-term option for not rolling your own, adapted  
versions for those find-modules. Of course, in the long run, the  
FindBLAS and FindLAPACK modules could query the enabled languages and  
based on that take different actions.

> I still think I have a valid use case and that it should not be a
> requirement for these CMake macro to have a Fortran compiler.
> Admittedly, it will be more difficult (but not impossible) to check  
> the
> presence of a symbol.

I'm not sure how to do that in a truly cross-platform way.

>
> But even if I had a Fortran compiler installed on my system, I think  
> it
> would still not be guaranteed that my program would link. The function
> tests are done with the Fortran compiler, but the program that needs  
> to
> be built will be compiled and linked with a C++ compiler. Hence, the
> name mangling issue remains AFAIK.


The name-mangling issue remains in your case, since you must link  
against the Fortran interfaces. However, if you used CBLAS and CLAPACK  
(both official interfaces) you wouldn't have that problem, because the  
issues have already been dealt with when linking those libraries in  
the first place.

>
> Best regards,
> Marcel Loose.
>



Michael