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
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