[CMake] FIND_LIBRARY & TARGET_LINK_LIBRARIES

[Ette, Anthony (CDS)]

Background info:
On version 3.3.20150618. RedHawk Linux 5.1.1 (real-time variant of RHEL5).

Description:
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?

Steps to reproduce:
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 LIB_DIR=/sim/lib/v67/ihawk).

Example:
PROJECT(ec_interface)

# static arhive #1 from /sim/lib/v67/ihawk
FILE(TO_CMAKE_PATH $ENV{LIB_DIR} LIB_D)
FIND_LIBRARY(libshm NAMES shm PATHS ${LIB_D} NO_DEFAULT_PATH)
MESSAGE("libshm: " ${libshm})

# static archive #2 from /usr/lib
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)
ADD_EXECUTABLE(ec_interface ${SOURCES})
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.cpp.o -o ../../../../ec_interface -rdynamic /sim/lib/v67/ihawk/libshm.a -Wl,-Bstatic -lccur_fbsched -Wl,-Bdynamic

If I remove libccur_fbsched from the TARGET_LINK_LIBRARIES, the resulting linker command is:

/usr/bin/g++   -O3 -DNDEBUG   CMakeFiles/ec_interface.dir/ec_interface.cpp.o -o ../../../../ec_interface -rdynamic /sim/lib/v67/ihawk/libshm.a

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 different 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"?

Lastly, I've found that if I instead ADD_LIBRARY as shown below, I can force the generated link command to use simply "/usr/lib/libccur_fbsched.a" as desired although I don't believe this is the recommended way of doing things. I thought FIND_LIBRARY was supposed to be used here (whereas ADD_LIBRARY is intended to be used when the library is created within the scope of current CMake project)?  Can anyone explain how/why CMake is generating different linker output for different static archives that are found using the same method (i.e. using FIND_LIBRARY then passing result to TARGET_LINK_LIBRARIES) where the extension is specified in one case but not the other?

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)

/usr/bin/g++   -O3 -DNDEBUG CMakeFiles/ec_interface.dir/ec_interface.cpp.o -o ../../../../ec_interface -rdynamic /sim/lib/v67/ihawk/libshm.a /usr/lib/libccur_fbsched.a


Thanks,
Anthony Ette
Technical Specialist, Software & Modeling

Rolls-Royce Controls and Data Services
7661 N Perimeter Rd
Indianapolis, IN 46241
tel: +1 (317) 230-6943
mob: +1 (317) 864-7975
email: Anthony.R.Ette at controlsdata.com<mailto:Anthony.R.Ette at controlsdata.com>

This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151102/d72e49ba/attachment.html>