Cygwin Python DLL and Shared Extension Patch

Jason Tishler Jason.Tishler@dothill.com
Thu Nov 9 06:44:00 GMT 2000


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CygwinPython-2.0-full.patch.gz
Type: application/x-gzip
Size: 18882 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20001109/fddd82e5/attachment.bin>


More information about the Cygwin mailing list