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. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
