Re: How to know what modules were dlpreopen-ed?

[Kevin P. Fleming]

Gary V. Vaughan wrote:

> I've not come across needing to dynamically determine the names of 
> statically preopened modules with ltdl before, and there is no API 
> support for that, but since your Makefile.am has to know which modules 
> were preopened (when it passes the -dlopen flags to libtool), why not 
> generate a header that contains the module names?

Well, therein lies the rub, my configure script itself does not know 
the list of modules either. I generate Makefile.am using a bootstrap 
script that scans the source directories for module files, because the 
application is still in a state of flux and the list changes, plus the 
user can add their own modules if they desire by just dropping a .c 
file into the proper directory. So I don't actually know the list at 
any point where I could create a header file, although I could do so 
with my bootstrap script, but then I don't know if they will really be 
preloaded or not because the user may decide to leave --enable-shared 
in effect...

> Maybe you can persuade us that API support for this would be good, and 
> supply us with a patch to implement it?  It should just be a simple 
> matter of walking through lt_preloaded_symbols and looking for elements 
> with NULL addresses (these are the module names, or @SELF@ for 
> dlpreopened self).

(for onlookers, it's actually @PROGRAM@ instead of @SELF@)

Yes, this is what I'm doing in my app right now; I added an "extern 
... lt_preloaded_symbols[]" declaration and I scan it for NULL 
addresses that are not @address@hidden That gets me the names I can pass to 
lt_dlopen, and it seems to work fine.

Most likely the ideal way to implement an API change would be to add a 
 lt_dlpreloadforeach, that works the same way lt_dlforeach does but 
for preloaded symbols (it would have to call lt_dlopen internally to 
get lt_dlhandles for all of them first, though). I can certainly 
supply a patch for this if you like.