Re: [CMake] target_link_libraries of MODULE
On 01/12/2013 11:04 PM, Rolf Eike Beer wrote:
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 dlopenable 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.
Good, example. I didn't considered this situation...
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 ;)
I will let the link with the core library and try to solve my problems in this
configuration...
Thank for your advices.
Paul.
Eike
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] target_link_libraries of MODULE
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 dlopenable 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 !
Regards.
Paul.
P.S i use a 2.8.10 version of cmake.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] target_link_libraries of MODULE
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 dlopenable 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
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
