[CMake] C++ linkage, Fortran standard lib

Nico Schlömer nico.schloemer at gmail.com
Fri Jan 14 14:51:51 EST 2011


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

It does indeed. Another way is to force a Fortran linker by

SET_TARGET_PROPERTIES( ${MY_EXECUTABLE} PROPERTIES LINKER_LANGUAGE Fortran )

Both not very nice.

Your suggestion is correct though: Each package should leave
information behind on how exactly it was built. Now that LAPACK uses
CMake to build, maybe there's a fair chance we get there; I'll ping
them about it.

Cheers,
Nico




On Fri, Jan 14, 2011 at 3:03 PM, Brad King <brad.king at kitware.com> wrote:
> 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
>


More information about the CMake mailing list