Matthias Klose <d...@debian.org> writes: > python uses <module_name>_init for extension modules / builtins to > initilize these. So it's part of the ABI as well. Not sure how to > change that.
No, it uses `initMODULE' for that: <https://docs.python.org/2/library/imp.html#imp.load_dynamic>: : imp.load_dynamic(name, pathname[, file]) : : [...] The name argument is used to construct the name of the : initialization function: an external C function called initname() in : the shared library is called. [...] This convention isn't especially good, but at least it's documented, and I'm not especially concerned about it. But since you bring the subject up: Python finds initialization functions for dynamically loaded extension modules by calling `dlsym(obj, "initMODULE")', having previously opened the dynamic object with `dlopen' using the flags maintained by `sys.[gs]etdlopenflags' (Python/dynload_shlib.c: _PyImport_GetDynLoadFunc) which default to omitting `RTLD_GLOBAL' (Python/pystate.c:PyInterpreterState_New), so the symbol remains local to the extension module. For built-in extension modules, the interpreter searches a simple table mapping module names to initialization functions (somewhat of a tangle in Python/import.c), so nothing legitimately depends on the dynamic symbol names. Anyway, I don't really have a problem with `init_md5' (Modules/md5module.c), which initializes the (builtin since 2.7.3-16) `_md5' module, but I do have a problem with `md5_init' (Modules/md5.c), which just initializes a hash context. -- [mdw]
