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