[Top][All Lists]

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

ltdl dlpreopen behavior

From: David Collett
Subject: ltdl dlpreopen behavior
Date: Thu, 4 Aug 2005 23:39:41 +1000

Hi all,
I am a little confused by dlpreopening in ltdl, it isnt doing quite
what I expected. My requirements are something like this:

I have a basic program which supports dynamically loaded modules
(using ltdl). I use auto* to configure it and at configure time select
which modules to build. This currently works just fine.

I'd now like to extend this such that at configure time, the modules
to be built can be specified as either "builtin" or "module".
"builtin" meaning that the actual object would be build right into the
main executable, "module" meaning that an so/dll would be built which
could be loaded at runtime.

I hoped that dlpreopening could be used for this purpose and i
modified to support either -dlopen or -dlpreopen per
module depending on configure args. The problem is that dlpreopen does
not cause the objects to be compiled in, rather it still produces a
so/dll, but compile-time links it to the executable (such that ldd
displays the dependancy).

Is there a way to change this behavior such that dlpreopend objects
get compiled right in?

BTW. I have found another way of achieving this result: having two
libtool library targets with different names for the same module
source, one a convienience library, and the other a module. Makefile
substitutions to the appropriate ones to the LDADD line as required.
The only problem is that loading code is now different for builtin vs
modules. I am solving this with a substitution into my actual C code,
but thats kind of ugly...

Any suggestions? I imagine my program would be a fairly common design
wrt builtin+optional modules (the linux kernel is an obvious example).


reply via email to

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