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