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

[Gary V. Vaughan]

Kevin P. Fleming wrote:
> 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...

Hmmm. Shouldn't the user add a module by installing a libtool module (.la/.so 
pair) into the runtime searchpath?  Are you trying to support modules on 
platforms that have no dynamic shared objects?  There was talk of putting 
extra information in a module .la file to allow an application to statically 
relink itself and exec a while ago.  Maybe you would like something like that?

> > 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@)

Thanks.

> 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.

lt_dlforeach already calls a user function for each loaded module, perhaps all 
that is needed is:

    int lt_dlispreload (lt_dlhandle handle);

lt_dlforeachfile can be used to load the modules in the path (be they 
preloaded or dynamic).  I can't really think of a reason why you would want to 
treat a preloaded module differently than a runtime loaded module, and we went 
to some lengths to hide the differences at the API level.

Perhaps if you explained what it is you are doing with loadable modules, and 
why you want to identify the preloaded ones during initialisation, as opposed 
to just loading the .la modules in a given searchpath using lt_dlforeachfile I 
would be able to understand your needs...

Cheers,
        Gary.
--
  ())_.  Gary V. Vaughan    gary@(lilith.warpmail.net|gnu.org)
  ( '/   Research Scientist http://www.oranda.demon.co.uk       ,_())____
  / )=   GNU Hacker         http://www.gnu.org/software/libtool  \'      `&
`(_~)_   Tech' Author       http://sources.redhat.com/autobook   =`---d__/