Cygwin Python DLL and Shared Extension Patch
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
Jason Tishler wrote:
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.
I think our goal for distutils should be to provide a cygwin build target -- not encourage people to continue to use the old Makefile.pre.in method. Apart from that, I like the idea of being able to build Python using cygwin tools on Windows. This opens new possibilities for people who don't have access to a compiler on Windows. BTW, do the extensions build using cygwin also work with the stock Python 2.0 installation ? AFAIR there have been a few problems with this in the past. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Marc-Andre, On Fri, Nov 10, 2000 at 04:32:41PM +0100, M.-A. Lemburg wrote:
I think our goal for distutils should be to provide a cygwin build target -- not encourage people to continue to use the old Makefile.pre.in method.
Sorry for the inappropriate post. I'm really just a Cygwin person trying to get up to speed with Python.
Apart from that, I like the idea of being able to build Python using cygwin tools on Windows. This opens new possibilities for people who don't have access to a compiler on Windows.
I agreed and hope that people find at least some of my patch useful. Any suggestions on how to move forward? Should I just redo the patch against Python CVS and submit it to the Patch Collector? I was hoping to get some feedback before doing so.
BTW, do the extensions build using cygwin also work with the stock Python 2.0 installation ? AFAIR there have been a few problems with this in the past.
Some extensions built with Cygwin will, mine won't. My extensions are standard Cygwin DLLs not to be confused with extensions built with mingw or with Cygwin using the -mno-cygwin option. They are linked with a Cygwin Python import library and not the stock Win32 Python one. They are also dependent on the Cygwin POSIX emulation DLL, cygwin1.dll. 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
[This discussion doesn't really belong here... perhaps python-dev would be a better place ?!] Jason Tishler wrote:
I like the idea of being able to build Python using cygwin tools on Windows. This opens new possibilities for people who don't have access to a compiler on Windows.
I agreed and hope that people find at least some of my patch useful. Any suggestions on how to move forward? Should I just redo the patch against Python CVS and submit it to the Patch Collector? I was hoping to get some feedback before doing so.
If the patch allows compiling Python with cygwin tools, I think this would be a valuable addition to the Python supported compiler backends. However a couple of things need to be tested: * Does Python compile without warnings ? * Does the patch interfere with any other compiler backends on the targetted platforms ? * Does the compiled Python version pass the regression suite ? * Are there any issues to be considered, e.g. wrt to licensing ? * Is there enough documentation to allow the average user with some C background to setup a compiler environment which then compiles Python out of the box ? More specifically: * Since we already have a compiler backend on Windows, are there ways to enable/disable compiling a version which works together with MS VC compiled extensions ? Anyway, I don't see any reason why not to upload the patches to SF -- they will get more visibility there than in this forum.
BTW, do the extensions build using cygwin also work with the stock Python 2.0 installation ? AFAIR there have been a few problems with this in the past.
Some extensions built with Cygwin will, mine won't. My extensions are standard Cygwin DLLs not to be confused with extensions built with mingw or with Cygwin using the -mno-cygwin option. They are linked with a Cygwin Python import library and not the stock Win32 Python one. They are also dependent on the Cygwin POSIX emulation DLL, cygwin1.dll.
Ok. So there's a gotcha in there which needs to be highlighted. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Marc-Andre, On Sat, Nov 11, 2000 at 11:39:28AM +0100, M.-A. Lemburg wrote:
[This discussion doesn't really belong here... perhaps python-dev would be a better place ?!]
I will heed the above suggestion and move this discussion to a more appropriate forum. Also, I will attempt to address your issues there. I apologize for the noise. Anyway, I do really appreciate the time that you have taken to respond to my posts. 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
participants (2)
-
Jason Tishler -
M.-A. Lemburg