MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013249CMakeCMakeSetuppublic2012-05-25 14:072016-06-10 14:31
ReporterTravis Horine 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformLinuxOSRedHat EnterpriseOS Version5
Product VersionCMake 2.8.4 
Target VersionFixed in Version 
Summary0013249: Static fortran executables fail to build due to a missing libintlc reference.
DescriptionNot 100% sure if this is a bug but thought I should submit it just in case.

As I understand it, the first time cmake runs it tries to figure out some basic things like which compiler to use and what the compiler needs by way of basic flags,etc... I'm not sure why but according to the CMakeOutput.log generated during this compiler detection phase, cmake is trying to collect an explicit list of the implicit libraries used by the compiler. It then apparently applies these implicit libraries explicitly to each target link when the target was built with the associated compiler.

Assuming that is what is happening then there may be a problem with that approach using the Intel 12.0.2 fortran compiler. That compiler reports the implicit use of a so called 'intlc' library which appears to only exist in shared object form on my machine. I think the compiler reports this as an implicit library because CMake is invoking it with the '-i_dynamic' flag (see cmake-2.8.4/share/cmake-2.8/Modules/Platform/Linux-Intel-Fortran.cmake). '-i_dynamic' is ostensibly slang for the 'shared-intel' flag.

Since this -i_dynamic flag causes the intel compiler to report 'intlc' as an implicit library the -lintlc flag is therefore being explicitly appended to any link commands even when the '-static' flag is also present.

Although my executable does not actually need this intlc library (ie...I can remove it manually from the link line and get a functional static build) the compiler fails to compile when the '-static' flag is present simply because it cannot find a static version of the intlc library ie.. 'libintlc.a'

Assuming it is important for CMake to continue to explicitly list the normally 'implicit' libraries on the link lines then there may be a need to weed out those libraries which do not have static counter parts for a given compiler. At least, my workaround for this has been to use

LIST(REMOVE_ITEM CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES intlc)

in my CMakeLists.txt file before trying to build the static executable.

Steps To Reproducebasically: Use add_executable to build a fortran executable with CMAKE_EXE_LINKER_FLAGS set to "-static".

In my case, (maybe this is important) I am building a mixed language executable where the C++ compiler (icpc) builds an object, the Fortran compiler (ifort) builds an object and then the C++ compiler (icpc) is invoked for linking the two objects into a static executable.

Additional InformationMy CMakeList file is something like this:

SET(CMAKE_EXE_LINKER_FLAGS "-static")
ADD_EXECUTABLE(file file.cpp)
TARGET_LINK_LIBRARIES(file alib blib)

Where alib is a library built in the parent directory and blib is a library built in a subdirectory of the file.cpp source.
Tagsfortran, intel, linker
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-05-25 14:07Travis HorineNew Issue
2012-05-25 14:15Travis HorineNote Added: 0029567
2012-05-25 14:24Travis HorineTag Attached: compiler
2012-05-25 14:24Travis HorineTag Attached: fortran
2012-05-25 14:24Travis HorineTag Attached: intel
2012-05-25 14:24Travis HorineTag Detached: compiler
2012-05-25 14:24Travis HorineTag Attached: linker
2012-05-25 14:47Brad KingNote Added: 0029568
2012-05-25 14:47Brad KingStatusnew => backlog
2012-05-25 15:25Travis HorineNote Added: 0029569
2016-06-10 14:28Kitware RobotNote Added: 0042054
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0029567)
Travis Horine   
2012-05-25 14:15   
Note that in my 'Additional Information' section I failed to mention that 'blib' is a fortran built library which is probably why CMake is including CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES on the link line when it builds the 'file' executable.
(0029568)
Brad King   
2012-05-25 14:47   
You've already analyzed the problem quite extensively and correctly.

The mixed-language nature of your use case is important. That is why you see the implicit libraries being added explicitly. CMake detects the implicit libraries passed by the front-end for each language to the linker. When linking a mixed-language binary CMake can only drive it through one language's front-end (the "LINKER_LANGUAGE"). Of course that means that the front-end will not add the implicit libraries that are unique to the other languages, so CMake adds them explicitly.

When CMake performs its initial tests to detect the implicit libraries it does so using dynamic linking. Therefore the list of libraries used by each front-end is for that case. The extracted list is valid only for dynamic linking and breaks for static linking as you've discovered. If one could convince CMake to use -static during its initial detection step the problem may go away for static linking but start appearing for dynamic linking (if both are done in one project).

This touches on the more general problem that CMake doesn't have a first-class interface to enable static linking. If it did then CMake could know that it needs to detect the implicit libraries for the dynamic and/or static cases. Establishing such a first-class interface is non-trivial but would be a general solution. If anyone is interested in pursuing this please say so in a note here. For now I'm moving this to the "backlog" status waiting for a volunteer.

Meanwhile I think your workaround is the simplest solution.
(0029569)
Travis Horine   
2012-05-25 15:25   
Ahh, I see. That makes sense about having to use the libs explicitly to handle mixed-language executables.

Sounds like static build options might be a good candidate for a future release then. I would volunteer to work on the missing interface if somebody would volunteer to pay me; ha :). Seriously, I might take a look at it sometime (pro-bono) but for now I am pretty swamped with projects so I will just have to see how far the workaround gets me.

Thanks for your explanation on the mixed-language stuff.
(0042054)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.