[CMake] TARGET_LINK_LIBRARIES for library targets?

Convey, Christian J CIV NUWC NWPT christian.convey at navy.mil
Fri Oct 10 14:39:34 EDT 2008


I've got three libraries, A, B, C.  C uses symbols from B, and B uses
symbols from A.

When I build these libraries as static libraries (libA.a, libB.a, and
libC.a), the linker is perfectly happy to produce libC.a even if I
haven't told it about B.  It seems that all that matters is, when I'm
linking together some executable program that uses libC.a, I have to
tell the linker about libB.a and (presumably) libA.a.

When I tried building my libraries as shared objects, however, the
linker seemed much fussier.  When the linker was trying to produce
libC.so, it got very upset about the unresolved symbols in libC.so's
object code.  

To remedy this, I added this line:  "TARGET_LINK_LIBRARIES(C, B)" and
"TARGET_LINK_LIBRARIES(B, A)".  But I'm not sure I understand all the
ramifications of solving the problem this way.

For example, does that mean that libC.so will export not only its own
symbols, but also those provided by B and A?   And would that answer
change if I had build B and A as static libraries, while still building
C as a shared object?

Also, suppose I go back to building all my libraries as static
libraries.  Will there be any harm in having those TARGET_LINK_LIBRARIES
statements still in my CMakeLists.txt files?  And if I do leave them
there, does this mean that I can get away with just writing this:
   TARGET_LINK_LIBRARIES(myApp C)
rather than
   TARGET_LINK_LIBRARIES(myApp C B A)
since CMake could (potentially) have enough information to realize that
myApp has a transitive link-time dependency on B and A?

Thanks,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20081010/7aa758d8/attachment.htm>


More information about the CMake mailing list