[CMake] C++ linkage, Fortran standard lib

[Brad King]

On 01/13/2011 04:54 PM, Nico Schlömer wrote:
> about half a year ago, there's been a discussion here about C++
> linking with dependencies to libgfortran present which did not
> automatically get resolved. The issue evolved around the Trilinos
> toolkit.

I think you're referring to this:

  http://www.cmake.org/pipermail/cmake/2010-July/038172.html

Not much has changed.

> both BLAS and LAPACK contain references to the standard Fortran library
> depending on the platform, a fact that the (C++) client application
> cannot be aware of.

Unfortunately this is also a fact that CMake cannot know either because
nothing tells it so.  This is what I explained in the above-linked thread.

This is not specific to CMake, Fortran, or mixed Fortran/C++ code.  It is
a case of static libraries that have unknown dependencies.  Imagine trying
to use libtk.a without also linking to libtcl.a.  Everyone who links to
libtk.a knows that they also need to link to libtcl.a because this is
well-documented and not platform-specific.  Unfortunately in the case
under discussion here the dependencies are platform-specific and not
documented.

> Back then, the following workaround was suggested:
> The user "knows" what the necessary Fortran libraries are, and
> manually adds them to the link line of the client application. This
> could happen via the CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES variable
> for example.
[snip]
> Now, I have a similar code (Trilinos as well, it just so happens) and
> the same problem. As I'm using the same build system to build the code
> on several machines, however, I cannot just hardcode the link
> libraries.

No one should set CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES or hard-code
Fortran runtime libraries.  The set() calls you see in the above-linked
thread come from files generated by CMake.  The workaround suggested was
to include a dummy Fortran source file in the client application to
convince CMake to link to the Fortran libraries too.  That will work for
your case too.

A full solution to this problem is to somehow detect the dependencies of
the blas and lapack static libraries.  Unfortunately there is no telling
which Fortran compiler, if any, was involved in producing a given archive.
Furthermore we do not know which objects in the archive might depend on
Fortran runtime library symbols, or even which symbols to reference in
a test project to bring in those objects in the first place.  Really it
needs to be up to the package providing the blas and lapack archives to
somehow document their dependencies or at least which Fortran compiler
was used to build them.

-Brad