Attached is a patch that builds Cygwin Python with its core as a DLL -- similar to the way that one builds Win32 Python. Once Cygwin Python is built as a "shared library" (i.e., DLL), one can build extensions using the same procedure as on other UNIX platforms that support shared libraries. It's as easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f Makefile.pre.in boot, make. Actually, attached is two versions of the same patch. The first one is the real patch but requires autoconf. The second one was generated after I ran autoconf and hence only requires the more typical build environment. Use the following procedure to patch and build Cygwin Python if you *have* autoconf: $ tar -xvzf Python-2.0.tar.gz $ cd Python-2.0 $ patch -p1 <../CygwinPython-2.0-minimal.patch $ autoheader $ autoconf $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install Use the following procedure to patch and build Cygwin Python if you *do not* have autoconf: $ tar -xvzf Python-2.0.tar.gz $ gunzip CygwinPython-2.0-full.patch.gz $ cd Python-2.0 $ patch -p1 <../CygwinPython-2.0-full.patch $ configure --with-threads=no --with-libm= --with-suffix=.exe $ make $ make install To test out shared extensions, try the following: $ cd Demo/extend $ make_shared $ python Python 2.0 (#1, Nov 1 2000, 08:51:39) [GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01 Type "copyright", "credits" or "license" for more information. >>> import xx >>> dir(xx) ['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj'] >>> xx.foo(2, 3) 5 As a more realistic example, I was able to build python-ldap 1.10alpha3 (http://sourceforge.net/projects/python-ldap) with the following minimal changes: 1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__) as described in http://www.python.org/doc/FAQ.html#3.24 2. added DL_EXPORT to init_ldap() Note that there were no changes of any kind to the build files (i.e, configure.in, Makefile.in, and Modules/Setup.in) or functionality changes to the C source. My goal is to ultimately submit the patch (redone against Python CVS) to the Python patch collector. I am hoping interested people will help me refine the patch before submittal. The following is an annotated ChangeLog for the patch: Wed Nov 8 23:22:46 2000 Jason Tishler <jt@dothill.com> * Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Makefile.in (altbininstall): Enhance altbininstall rule to also install the Cygwin Python DLL. * Makefile.in (libainstall): Change libainstall rule to install LDLIBRARY instead of LIBRARY. Will installing LDLIBRARY instead of LIBRARY break other platforms? The terse description of LDLIBRARY in configure.in seems to indicate that possibly the original build procedure should be been installing it instead of LIBRARY. Anyway, I am very willing to change the patch to install both LDLIBRARY and LIBRARY (if they are different) or some other suitable solution. * Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY. * Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build the Cygwin Python DLL. Should the body of this rule be hidden in a shell script? I have stumbled across various platform specific scripts like BeOS/ar-fake that has me thinking that this may be desirable. If not, then I will clean up the rule to use variables like LDSHARED instead of "gcc -shared", etc. * Modules/makesetup: Add shell variable module and default its value to "module". * Modules/makesetup: Add Cygwin specific definitions to set shell variables module, CygwinFlags, and CygwinLibs appropriately. Is it undesirable to put platform specific code in makesetup? * Modules/makesetup: Add .def to the list of known file types. * Modules/makesetup: Change object rule to include CygwinFlags. * Modules/makesetup: Change to use shell variable module instead of hardcoded "module". * Modules/makesetup: Change shared extension rule to include CygwinLibs. * acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and DL_EXPORT. Is there a better way of accomplishing this without affecting config.h on all other autoconf supported platforms too? * configure.in: Add autoconf variable SET_DLLLIBRARY. * configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY appropriately. I have chosen to call the import library libpython$(VERSION).dll.a and the DLL libpython$(VERSION).dll. Recently there has been a proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html) to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order to avoid clashing with Win32 versions of the same DLL. I have stayed with libpython2.0.dll because it is more consistent with the UNIX naming convention and because there is no (current) possibility of clashing with the Win32 Python DLL, python20.dll. Nevertheless, I am willing to change the name of the Cygwin Python DLL, if desired. * configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately. * configure.in: Add Cygwin case to set SO appropriately. * configure.in: Add Cygwin case to set LDSHARED appropriately. Should LDSHARED contain more flags? For example, -Wl,--enable-auto-image-base, etc.? Any feedback is greatly appreciated. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corporation Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com