[CMake] target_link_libraries of MODULE

[Rolf Eike Beer]

Paul Chavent wrote:
> Hi.
>
> I'm working on a project basically compound of :
>
>  - a core library that can be static or dynamic
>
>  add_library(Foo-lib ${FOO_LIB_SOURCES})
>
>  - an executable that rely on the main library :
>
>  add_executable(Foo-bin ${FOO_BIN_SOURCES})
>  target_link_libraries(Foo-bin Foo-lib)
>
>  - a "dlopen"able plugin that need some functions of the Foo library 
> :
>
>  add_library(Foo-plugin MODULE ${FOO_PLUGIN_SOURCES})
>  target_link_libraries(Foo-plugin Foo-lib)
>
> I don't need the last line under linux : i usually don't link
> Foo-plugin against Foo-lib.
> And that's good because if i choose to build a static Foo-lib, i
> don't want in Foo-plugin all symbols that will be already present in
> Foo-bin.
>
> Under Windows (MinGW) or MacOSX, without this last line i have
> unresolved symbols when i compile Foo-plugin. So i let it be.
> The problem comes when i try to compile static Foo-lib. I have
> segfault at the Foo-plugin load time, probably because of some static
> class/variables initializations.
>
>
> What is the good practice please ? Isn't there any option to tell to
> ignore unresolved symbols for MODULE ? They will be resolved at load
> time !

They wont, or only by chance. In fact you would need the link line on 
many recent Linux distributions also, that depends on the link flags. 
Take the situation where you have a static library: the symbols of that 
library may me removed by a linker that is advanced enough, as it may 
detect that they are never called from inside your executable. So they 
are gone when your plugin comes to life and it may need them. So: yes, 
you always need to link.

I have no idea what your problems with a static lib are, but static 
class objects are usually a bad idea, for reasons you may already have 
found out ;)

Eike