View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0013249 | CMake | CMakeSetup | public | 2012-05-25 14:07 | 2016-06-10 14:31 | ||||
Reporter | Travis Horine | ||||||||
Assigned To | Kitware Robot | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | moved | ||||||
Platform | Linux | OS | RedHat Enterprise | OS Version | 5 | ||||
Product Version | CMake 2.8.4 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0013249: Static fortran executables fail to build due to a missing libintlc reference. | ||||||||
Description | Not 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 Reproduce | basically: 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 Information | My 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. | ||||||||
Tags | fortran, intel, linker | ||||||||
Attached Files | |||||||||
Relationships | |
Relationships |
Notes | |
(0029567) Travis Horine (reporter) 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 (manager) 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 (reporter) 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 (administrator) 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. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2012-05-25 14:07 | Travis Horine | New Issue | |
2012-05-25 14:15 | Travis Horine | Note Added: 0029567 | |
2012-05-25 14:24 | Travis Horine | Tag Attached: compiler | |
2012-05-25 14:24 | Travis Horine | Tag Attached: fortran | |
2012-05-25 14:24 | Travis Horine | Tag Attached: intel | |
2012-05-25 14:24 | Travis Horine | Tag Detached: compiler | |
2012-05-25 14:24 | Travis Horine | Tag Attached: linker | |
2012-05-25 14:47 | Brad King | Note Added: 0029568 | |
2012-05-25 14:47 | Brad King | Status | new => backlog |
2012-05-25 15:25 | Travis Horine | Note Added: 0029569 | |
2016-06-10 14:28 | Kitware Robot | Note Added: 0042054 | |
2016-06-10 14:28 | Kitware Robot | Status | backlog => resolved |
2016-06-10 14:28 | Kitware Robot | Resolution | open => moved |
2016-06-10 14:28 | Kitware Robot | Assigned To | => Kitware Robot |
2016-06-10 14:31 | Kitware Robot | Status | resolved => closed |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |