If dynamic loading in supported, then 'import' checks for both
.py, .pyc, or .o ( or .so ) files. If an object file is loaded,
there should be an init[module-name]() function entry point, which
is the only entry point that has to be exported from the module.
That function calls initmodule() with the module name and a structure
of name, object pairs that is used to build the modules dictionary
namespace. This is exaclty the same thing that is done on a statically
builtin object module - the only difference is an extra call or two
to get the initXXX entry point.
On AIX, which doesn't use the dlopen routines, a system routine
'load()' returns a single entry point, that is determined by the
'-start' flag when linking it into a shared object library.
The loaded module will have to call initmodule, and mostlikely
newstringobject, and all sorts of modsupport routines. I'm not
sure how the dl-library does this back-from-the-main-program
symbol resolution. On AIX, the mail python routine needs to
be built with an list of exported symbols, and the dynamically
loaded module has to use that as an import list when it is linked,
for those symbols to be resolved at run/load time. ( It would
probably work better if I built modsupport and some other
routines into a library sharable by both pythonmain and the
dynamically loadable modules. )
[ So linking a loadable object on AIX requires '-start initXXX'
'-bM:RE' switches and an imports (from main python) symbol file. ]
For us unix folk, it's not so bad to have to relink to add
a new module. You rarely have to do a complete 'make clean',
if you are just adding a module, so it doesn't take long
to build. The platforms where dynamic loading would be
the biggest win would be on DOS and Mac, where not everyone
has a development system on every machine.
Some (MS) Windows Wizard out there ought to be able to figure
out how to build Python as a bunch of DLL modules, and get
dynamic loading on DOS+WINDOWS.
The Mac has a general way of loading code resources, but I
don't know if there is a way to do the back resolution
without a linker. Maybe all of the support functions
have to be identified and put into their own segment/resource
with an indirect jump table. (?)
For all systems, it might be helpful to at least figure
out a list of all of the support routines and other symbols
that could be required of a separately linked module.
-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --