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: [email protected]<mailto:[email protected]>
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.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
