[CMake] Linker error with sub project's static libs

[Marcel Loose]

Hi Olaf,

See my reply below inline.

On 21/08/14 20:19, Olaf Peter wrote:
> Hello Marcel,
>> Olaf,
>>
>> Unless your code snippets are incomplete, I'm missing the following
>> statement in ./source/eea/ui/CMakeLists.txt
>>
>>      target_link_libraries(eea_ui_lib
>>          eea_ui_schematic_lib)
>>
>> I'm not sure this is causing the link error, but it's worth a try.
> thank you a lot, this solves the linker problem - I have to add these
> twice, reference to the other lib each time.
>>
>> Furthermore, I think the order of add_subdirectory(), add_library(), and
>> target_link_libraries() is important. You might want to check those
>> as well.
> The order matches of course, but I haven't never such linker problems.
> The first time I'm using target_link_lib for a library self. The
> reason is not clear for me. What happens under the hood here?
Libraries can depend on one another. If code that produces libB uses
functions that are implemented in code that produces libA, then libB
depends on libA. When creating static libraries this doesn't make much
of a difference; after all a static library is just a bunch of object
files. However, when creating shared libraries it does. Shared library
libB will record internally that it depends on libA; something a static
library cannot do.

Suppose you're linking a main program that only uses functions defined
in libB. When using shared libraries, you only need to link your main
program against libB; remember, libB has recorded internally that it
depends on libA. However, when using static libraries you need to link
against libB and libA, even though your main program doesn't use any
functions in libA.

CMake to the rescue!

The only thing you have to tell CMake is that libB depends on libA,
using target_link_libraries(B A). CMake will then make sure that the
correct libraries on put on the link line in the correct order. There's
only one exception: circular dependencies. In that case you may need to
help CMake a bit. IMHO you should try very hard to avoid circular
library dependencies; they are a real PITA.
> Thanks,
> Olaf
>
Cheers,
Marcel Loose.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loose.vcf
Type: text/x-vcard
Size: 292 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20140822/b39a765b/attachment.vcf>