On Mon, 09/16 15:31, Richard Henderson wrote: > On 09/16/2013 04:46 AM, Fam Zheng wrote: > > On Mon, 09/16 13:33, Paolo Bonzini wrote: > >> Il 16/09/2013 13:29, Fam Zheng ha scritto: > >>> An idea for single .so file: > >>> - before loads a .so, an empty initializer list is created. > >>> - module_init adds a __attribute__((constructor)) function, which > >>> appends > >>> its real initializer to the initializer list. So this function is > >>> automatically called after dlopen(). > >>> - make init_$(date +%s$$$RANDOM) a dummy symbol. > >>> - module_load first checks the presense of the symbol, if yes, call > >>> the > >>> functions in the initializer list. Else clean up and unload .so. > >>> > >>> Does this enable multiple calls of module_init()? > >> > >> Yes. Basically you are delaying the constructors; that would work. > >> > >>> OTOH. As for multiple spice modules, is it possible to solve it by having > >>> a > >>> spice-common.o and link all spice modules to it, to share code? > >> > >> Looks like there is global state in ui/spice-core.c, so likely no. > >> > > > > What if the modules can be loaded by name? Then in spice-qemu-char.so, it > > can > > call require_module("spice-core") before initializing itself, which will > > load > > this dependency if not yet. This may be the simplest implementation of > > dependency resolving. > > Why oh why would you want to re-invent the dependencies that ld.so already > provides? > > Link spice-qemu.char.so against spice-core.so. The DT_NEEDED entry will be > recorded, and ld.so will do the right thing. > > Anything else sounds way too much like Not Invented Here. > How to do the symbol checking as above if spice-core.so is automatically loaded by ld.so?
And we will need to add $moddir to LD_LIBRARY_PATH and lose the restriction of modules directory too. Fam