MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011348CMakeCMakepublic2010-10-21 12:232010-10-26 12:14
ReporterJeff Hensley 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0011348: Why does Cmake use "-l" for linking when the actual (static) library is given?
DescriptionI'm having to jump through some hoops while using Cmake because it seems to recognize that given libraries are in known locations, and then provides links to them via the -l flag even though we are providing the actual location and name of a library (*.a).

Note: this is on an HPC platform. cc is a wrapper script that sets up the MPI and other niceities. cc is thus a front end to different compilers which is changed by using the module command.
Steps To Reproduce
Additional InformationConsider the following simple example:

project (foo C)
add_executable(foo foo.c)
set(executable_name "foo")

set(ZLIB_LIBRARY "/usr/lib64/libz.a") #Option 1
#set(ZLIB_LIBRARY "/u/hensley/libz.a") #Option 2

target_link_libraries(${executable_name} ${ZLIB_LIBRARY})

***************************

The link line is completely different depending on which libz I point to. In the Option 1, libz.a is in a standard library location. It appears that cmake identifies this and rather than using "/usr/lib64/libz.a" in the link, it uses "-lz".

Here is link.txt:

/opt/cray/xt-asyncpe/3.3/bin/cc CMakeFiles/foo.dir/foo.c.o -o foo -Wl,-Bstatic -lz -Wl,-Bdynamic



Now, if I use the second option, the resulting link line is:

/opt/cray/xt-asyncpe/3.3/bin/cc CMakeFiles/foo.dir/foo.c.o -o foo /u/hensley/libz.a


On this platform, I *absolutely must* link statically. But, I'm attempting to ensure this by pointing *always* to static objects. But cmake is getting ahead of me and thwarting my efforts.

Now, I just ran across "LINK_SEARCH_END_STATIC" which might allow me to work around this (IF I can figure out how to use that), but it seems counter-intuitive to me that I would have to jump through yet more hoops to tell cmake to do what I've always been telling it to do!

Any insight would be appreciated. Also, if LINK_SEARCH_END_STATIC can be used to "fix" this, I could use a simple example. Thanks!


TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-10-21 12:23Jeff HensleyNew Issue
2010-10-21 13:02Bill HoffmanStatusnew => assigned
2010-10-21 13:02Bill HoffmanAssigned To => Brad King
2010-10-26 12:14Brad KingNote Added: 0022704
2010-10-26 12:14Brad KingStatusassigned => closed
2010-10-26 12:14Brad KingResolutionopen => no change required

Notes
(0022704)
Brad King   
2010-10-26 12:14   
Normally CMake does preserve the full path you provide, but not for libraries in implicit linker search directories like /usr/lib. This is because sometimes the real implicit linker search path under the hood is something like /usr/lib/$arch because the toolchain substitutes architecture-specific libraries at link time. If we leave the full path intact then the wrong architecture is used and the link fails.

There is a ways to tell CMake to *always* use the full path. Use an IMPORTED target:

add_library(z STATIC IMPORTED)
set_property(TARGET z PROPERTY IMPORTED_LOCATION /usr/lib/libm.a)
...
target_link_libraries(myexe z)