[CMake] Cmake and Libltdl

Michael Hertling mhertling at online.de
Mon Jun 21 02:56:54 EDT 2010


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


More information about the CMake mailing list