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

Marcel Loose loose at astron.nl
Tue Jul 7 09:51:33 EDT 2009


On Tue, 2009-07-07 at 14:08 +0200, Michael Wild wrote:
> 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

OK,

I'll roll my own then.

Should I file a feature request for FindBLAS/FindLAPACK not requiring a
Fortran compiler?

Best regards,
Marcel Loose.




More information about the CMake mailing list