[Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch

Thu, 16 Nov 2000 07:40:08 -0800

Patch #102409 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Cygwin Python DLL and Shared Extension Patch

Follow-Ups:

Date: 2000-Nov-16 07:40
By: jlt63

Comment:
This patch builds Cygwin Python with its core as a DLL -- similar to
the way that Win32 Python is built.  Once Cygwin Python is built as a
"shared library" (i.e., DLL), the procedure for building extensions is
the same as on 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.

The following is the procedure to apply the patch and build Cygwin Python:

	$ patch -p0 <Cygwin-1.1.5-Python-2.0.patch
	$ autoheader
	$ autoconf
	$ 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.

The following is an annotated ChangeLog for the patch:

Thu Nov 16 10:38:20 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.

	* 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 LN appropriately.
	* configure.in: Add Cygwin case to set OPT 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.?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470