Re: [CMake] Cmake and Libltdl
On 06/19/2010 09:41 AM, Carlos Lopez Gonzalez wrote: On Fri, 18 Jun 2010 10:40:46 +0200 Michael Hertling wrote: On 06/17/2010 11:29 AM, Carlos Lopez Gonzalez wrote: Hi, I'm new to cmake and want to port a C++ project which is now built using autotools to cmake build system. The project has some libraries (we call them modules) which are used in two applications. The applications uses lt_dladdsearchdir to add the path where to search the modules and then uses the lt_dlopenext and lt_dlsym to register the modules. When using cmake, do I need to use ltdl as well or will cmake replace the way the libraries are found and registered? If your project's libraries are actually to be loaded dynamically at the behest of the applications, i.e. dlopened, you further need a library to achieve this as it is a runtime affair and, thus, beyond CMake's scope, so stay with libltdl or switch to the simpler libdl, e.g., if you want to get rid of the libtool stuff. In either case, you should build dlopened libraries with ADD_LIBRARY(...MODULE...) in order to prevent other binaries to link against them explicitly. If your libraries don't need to be dlopened - your question somewhat seems to be targeted on this - you should build them as ordinary shared libraries with ADD_LIBRARY(...SHARED...) and link other binaries against them with TARGET_LINK_LIBRARIES(), so the runtime linker automatically takes care to load them when the applications are launched. To ensure they are found after being installed at a perhaps unusual location, look at CMake's RPATH support, e.g.: http://www.cmake.org/Wiki/CMake_RPATH_handling 'hope that helps. Regards, Michael Hi Michael, now it makes much more sense. For whom has curiosity the project in particular is Synfig (http://synfig.org) Synfig is a a2D vector animation program and it has layers, importers and exporters. In Synfig, layers, importers and exporters instances are created based on a book of layers, importers or exporters. The program reads from file or from the user interaction what's the layer it needs to create based on the layer's name, what's the exporter it needs to create based on the extension of the file to export or what's the importer to instantiate based on the extension of the file which is being imported. So each module (layer, importer or exporter) is never called directly (like any other library) by the class name but by a factory (a pointer to the constructor) that is stored at the start up of the application in a book (std:map) of modules. So in one way or other, the application needs to know the pointer to the module before it is needed, so that's the reason for use libltdl. Just for my curiosity: If you know and load all those libraries in advance, i.e. at launch time, and if you know their names they are registered by in the mentioned std::map which advantage do you take of designing them as dlopened libraries compared to ordinary shared libraries? Thanks for pointing me to libld which I'll take a look. AFAIK, libltdl is mainly a wrapper around libdl and similar libraries to provide a consistent interface across several plattforms concerning dlopening whereas libdl - one of multiple *nix approaches - is part of a POSIX compliant system's C library, so the typical trade-off is, in short, portability beyond *nix against a decrease of dependencies. In any case, the ADD_LIBRARY are needed, right? Yes, if you want to build the modules along with the other targets within your project. Usually, dlopened libraries and ordinary shared libraries don't differ technically; on *nix, in fact, they're built by the same command. Their difference is rather a convention: One doesn't link explicitly against dlopened libraries as they are intended to be loaded at runtime, and this is enforced by ADD_LIBRARY(...MODULE...) in contrast to ADD_LIBRARY(...SHARED...). Regards, Michael ___ 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] Cmake and Libltdl
On Fri, 18
Jun 2010 11:23:48 +0200 Andreas Mohr wrote:
On Thu, Jun 17, 2010 at 10:25:10AM
-0400, cmake-requ...@cmake.org wrote:
Hi,
I'm new to
cmake and want to port a C++ project which is now built using autotools
to cmake build system.
The project has some libraries (we call
them modules) which are used in two applications. The applications uses
lt_dladdsearchdir to add the path where to search the modules and then
uses the lt_dlopenext and lt_dlsym to register the modules.
When using cmake, do I need to use ltdl as well or will cmake replace the
way the libraries are found and registered?
I'm now using a CMake setup with ltdl as well, and AFAIK there are no
special usability
improvements provided for plugins to be loaded via ltdl.
Probably one needs to add lt_dladdsearchdir() to match all the various
differing
plugin library paths that the CMake configuration might produce on various
platforms
'til one's nose gets green...
However, of course a
probably very elegant solution is to add a
PROJ_PLUGIN_DIR_BUILD=...
and/or PROJ_PLUGIN_DIR_INSTALL=...
to COMPILE_DEFINITIONS property or add_definitions(),
and then to simply use that in the project source to achieve a precise path:
#ifndef PROJ_PLUGIN_DIR_BUILD
#define
PROJ_PLUGIN_DIR_BUILD some_random_hardcoded_fallback
#endif
lt_dladdsearchdir(PROJ_PLUGIN_DIR_BUILD);
lt_dladdsearchdir(random_hardcoded_dir_a);
lt_dladdsearchdir(random_hardcoded_dir_b);
PROJ_PLUGIN_DIR_BUILD could probably be figured out using things such as
${LIBRARY_OUTPUT_PATH} or ${CMAKE_BINARY_DIR}/...
Andreas Mohr
Hi Andreas
As mentioned in the other reply, the application loads the libraries in a book
of libraries using the ltdl utilities.
None of the usage of the libraries are hardcoded because they are instantiated
based on the name of the library needed.
I now understand what's the libltdl usage and why it is not replaced by the
cmake ability to link the libraries in a dynamic way.
Wish me good luck with the implementation of the migration.
Thanks you all.
Carlos López
http://synfig.org
___
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] Cmake and Libltdl
On 06/17/2010 11:29 AM, Carlos Lopez Gonzalez wrote: Hi, I'm new to cmake and want to port a C++ project which is now built using autotools to cmake build system. The project has some libraries (we call them modules) which are used in two applications. The applications uses lt_dladdsearchdir to add the path where to search the modules and then uses the lt_dlopenext and lt_dlsym to register the modules. When using cmake, do I need to use ltdl as well or will cmake replace the way the libraries are found and registered? If your project's libraries are actually to be loaded dynamically at the behest of the applications, i.e. dlopened, you further need a library to achieve this as it is a runtime affair and, thus, beyond CMake's scope, so stay with libltdl or switch to the simpler libdl, e.g., if you want to get rid of the libtool stuff. In either case, you should build dlopened libraries with ADD_LIBRARY(...MODULE...) in order to prevent other binaries to link against them explicitly. If your libraries don't need to be dlopened - your question somewhat seems to be targeted on this - you should build them as ordinary shared libraries with ADD_LIBRARY(...SHARED...) and link other binaries against them with TARGET_LINK_LIBRARIES(), so the runtime linker automatically takes care to load them when the applications are launched. To ensure they are found after being installed at a perhaps unusual location, look at CMake's RPATH support, e.g.: http://www.cmake.org/Wiki/CMake_RPATH_handling 'hope that helps. Regards, Michael ___ 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] Cmake and Libltdl
On Thu, Jun 17, 2010 at 10:25:10AM -0400, cmake-requ...@cmake.org wrote:
Hi,
I'm new to cmake and want to port a C++ project which is now built using
autotools to cmake build system.
The project has some libraries (we call them modules) which are used in two
applications. The applications uses lt_dladdsearchdir to add the path where
to search the modules and then uses the lt_dlopenext and lt_dlsym to register
the modules.
When using cmake, do I need to use ltdl as well or will cmake replace the way
the libraries are found and registered?
I'm now using a CMake setup with ltdl as well, and AFAIK there are no
special usability improvements provided for plugins to be loaded via ltdl.
Probably one needs to add lt_dladdsearchdir() to match all the various differing
plugin library paths that the CMake configuration might produce on various
platforms
'til one's nose gets green...
However, of course a probably very elegant solution is to add a
PROJ_PLUGIN_DIR_BUILD=... and/or PROJ_PLUGIN_DIR_INSTALL=...
to COMPILE_DEFINITIONS property or add_definitions(),
and then to simply use that in the project source to achieve a precise path:
#ifndef PROJ_PLUGIN_DIR_BUILD
#define PROJ_PLUGIN_DIR_BUILD some_random_hardcoded_fallback
#endif
lt_dladdsearchdir(PROJ_PLUGIN_DIR_BUILD);
lt_dladdsearchdir(random_hardcoded_dir_a);
lt_dladdsearchdir(random_hardcoded_dir_b);
PROJ_PLUGIN_DIR_BUILD could probably be figured out using things such as
${LIBRARY_OUTPUT_PATH} or ${CMAKE_BINARY_DIR}/...
Andreas Mohr
___
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
