MantisBT - CMake
View Issue Details
0015823CMakeCMakepublic2015-10-31 14:462016-05-02 08:30
Anthony Ette 
 
normalmajoralways
closedno change required 
RedHawk LinuxRedHawk Linux5.1.1
CMake 3.3.2 
 
0015823: FIND_LIBRARY & TARGET_LINK_LIBRARIES
On version 3.3.20150618.
I am not understanding the behavior of these two commands or am getting inconsistent results. Sometimes when the results of a found static library from FIND_LIBRARY are passed to TARGET_LINK_LIBRARIES, it generates "/path/to/lib" linker syntax BUT other times it produces a "-Wl,-Bstatic -llib -Wl,-Bdynamic" syntax. I've confirmed that both lib vars as returned from FIND_LIBRARY are full paths to .a static archive files so how can the different handling at the linker CLI be explained?
Unknown. Some libs are handled one way and others are handled another. The only potential lead may be that they come from different paths on the file system (say one from /usr/lib and another from /sim/lib/v67/ihawk).
None
No tags attached.
Issue History
2015-10-31 14:46Anthony EtteNew Issue
2015-10-31 14:54Anthony EtteNote Added: 0039713
2015-10-31 14:58Anthony EtteNote Added: 0039714
2015-10-31 18:13Anthony EtteNote Added: 0039715
2015-11-02 08:52Brad KingNote Added: 0039718
2015-11-02 08:53Brad KingStatusnew => resolved
2015-11-02 08:53Brad KingResolutionopen => no change required
2016-05-02 08:30Robert MaynardNote Added: 0040953
2016-05-02 08:30Robert MaynardStatusresolved => closed

Notes
(0039713)
Anthony Ette   
2015-10-31 14:54   
Specific example:

PROJECT(ec_interface)

# static arhive #1
FILE(TO_CMAKE_PATH $ENV{LIB_INCL_DIR} LIB_INCL)
FIND_LIBRARY(libshm NAMES shm PATHS ${LIB_D} NO_DEFAULT_PATH)
MESSAGE("libshm: " ${libshm})

# static archive 0000002
FILE(TO_CMAKE_PATH /usr/lib USR_LIB)
FIND_LIBRARY(libccur_fbsched NAMES libccur_fbsched.a PATHS ${USR_LIB} NO_DEFAULT_PATH)
MESSAGE("libccur_fbsched: " ${libccur_fbsched})

SET(SOURCES ec_interface.cpp)

TARGET_LINK_LIBRARIES(ec_interface ${libshm} ${libccur_fbsched})


Notice in the resulting linker command below how libshm and libccur_fbsched are handled very differently, why is this?:

/usr/bin/g++ -O3 -DNDEBUG CMakeFiles/ec_interface.dir/ec_interface_w.cpp.o CMakeFiles/ec_interface.dir/ec_interface.cpp.o CMakeFiles/ec_interface.dir/resolver.c.o -o ../../../../ec_interface -rdynamic /sim/lib/v67/ihawk/libshm.a -Wl,-Bstatic -lccur_fbsched -Wl,-Bdynamic
(0039714)
Anthony Ette   
2015-10-31 14:58   
I guess it's also important to note that in LIB_D, only .a files exist (i.e. there is only a libshm.a and no libshm.so file). However, in /usr/lib, there are multiple files by the same name with differenet suffixes (e.g. libccur_fbsched.a, libccur_fbsched.so, etc.). That is why I am specifying the ".a" explicitly in the FIND_LIBRARY command for libccur_fbsched in an attempt to force it to pick up the static archive and not the dynamic ones. The message I'm printing seems to indicate it is using the static, so I still don't understand the resulting link command. How fine tuned of control do I have over the resulting link command? I.e. can I force libccur_fbsched to show up as "/usr/lib/libccur_fbsched.a" and not as "-Wl,-Bstatic -lccur_fbsched -Wl,-Bdynamic"?
(0039715)
Anthony Ette   
2015-10-31 18:13   
I've found that if I instead use the syntax below, I can force the generated link command to use simply "/usr/lib/libccur_fbsched.a" although I don't know if this is the recommended way of doing things. I thought FIND_LIBRARY was supposed to be used here although I just can't seem to control its behavior well enough?

ADD_LIBRARY(libccur_fbsched STATIC IMPORTED)
SET_PROPERTY(TARGET libccur_fbsched PROPERTY IMPORTED_LOCATION ${USR_LIB}/libccur_fbsched${LIBEXT})
TARGET_LINK_LIBRARIES(
    ec_interface
    ${libshm}
    libccur_fbsched
)
(0039718)
Brad King   
2015-11-02 08:52   
See https://cmake.org/cmake/help/v3.3/policy/CMP0060.html [^] for an explanation of this historical behavior. Set the policy to NEW to always get the full path as desired.
(0040953)
Robert Maynard   
2016-05-02 08:30   
Closing resolved issues that have not been updated in more than 4 months.