[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

modules dlopened from a library

From: Simon Richter
Subject: modules dlopened from a library
Date: Mon, 30 May 2005 14:42:14 +0200
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)


I have a shared library that internally uses plugins that are dlopened
(or dlpreopened). For this to work, I basically have the following options:

 - Have the application load the list of preloaded symbols. This means
that the application programmer needs to be aware that my library uses
ltdl, and that the library will fail in Unobvious And Interesting(tm)
ways if she forgets to do so.

 - Have the library load the list of preloaded symbols. This means that
any application will have to define lt_preloaded_symbols, even if it is
just a configure test application; also it introduces a dependency from
a library to the program, which is permitted on GNU systems at the cost
of a COW page being touched, but not very portable.

 - Have libtool add a specific .o file to every app. I'm not sure
whether this is possible in a sane way, hence I'm asking, but to me it
appears that if libtool could be kicked into adding a .o file to
dependency_libs when building the library, said file would be linked to
every application when libtool is used to link the app. This still means
that if the application is linked without libtool, it will fail in
U&I(tm) ways, but at least I can build a configure script that tests for
the library's presence, and be somewhat portable.

Is there another, perhaps more sane, way to achieve this?


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]