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
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
