Guido, I can't find the message, but it seems that at some point you mentioned wanting to break out importdl.c into separate files. The configure process could then select the appropriate one to use for the platform. Sounded great until I looked at importdl.c. There are a 13 variants of dynamic loading. That would imply 13 separate files/modules. I'd be happy to break these out, but are you actually interested in that many resulting modules? If so, then any suggestions for naming? (e.g. aix_dynload, win32_dynload, mac_dynload) Here are the variants: * NeXT, using FVM shlibs (USE_RLD) * NeXT, using frameworks (USE_DYLD) * dl / GNU dld (USE_DL) * SunOS, IRIX 5 shared libs (USE_SHLIB) * AIX dynamic linking (_AIX) * Win32 platform (MS_WIN32) * Win16 platform (MS_WIN16) * OS/2 dynamic linking (PYOS_OS2) * Mac CFM (USE_MAC_DYNAMIC_LOADING) * HP/UX dyn linking (hpux) * NetBSD shared libs (__NetBSD__) * FreeBSD shared libs (__FreeBSD__) * BeOS shared libs (__BEOS__) Could I suggest a new top-level directory in the Python distribution named "Platform"? Move BeOS, PC, and PCbuild in there (bring back Mac?). Add new directories for each of the above platforms and move the appropriate portion of importdl.c into there as a Python C Extension Module. (the module would still be statically linked into the interpreter!) ./configure could select the module and write a Setup.dynload, much like it does with Setup.thread. Cheers, -g -- Greg Stein, http://www.lyra.org/