[Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 10 Jan 2001 13:12:49 -0800
Patch #102409 has been updated.
Project: python
Category: Build
Status: Closed
Submitted by: jlt63
Assigned to : gvanrossum
Summary: Cygwin Python DLL and Shared Extension Patch
Follow-Ups:
Date: 2001-Jan-10 13:12
By: gvanrossum
Comment:
Checked in. Thanks!
Again, I've only verified that this doesn't break the Linux build.
-------------------------------------------------------
Date: 2001-Jan-08 18:14
By: jlt63
Comment:
This is the second version of the patch with the following
significant changes since the first version:
1. The standard modules also can be built as shared extensions
and they will have the same basenames as on other UNIX
platforms.
2. Fixed a problem that prevented the loading of multiple
shared extensions due to DLL base address conflicts.
Please see the ChangeLog below for more details. Otherwise,
the patch is essential the same as the previous one.
I agree with Tim's 2001-Jan-05 09:52 assessment of the patch
-- it is more important to determine whether this patch will
break other platforms than whether it works on Cygwin.
Although any change to the configure, makefile, and makesetup
infrastructure can break any platform (other than Win32), I feel
that the following change is the one that needs the most
scrutinizing:
* Makefile.in (libainstall): Change libainstall rule to install
LDLIBRARY instead of LIBRARY.
Although I have tested the patch on Linux and can do so on
Solaris, HP-UX, and Win32. Unfortunately, I cannot test it
on NeXT, DG/UX, or BeOS which are the only platforms that
currently use LDLIBRARY.
Can someone knowledgeable with these platforms be asked to
evaluate the impact on their respective platforms? Once this
issue is resolved, then I feel (possibly naively) that the
rest of the patch has a good chance of being accepted.
The following is an annotated ChangeLog for the second version of
the patch:
Mon Jan 8 20:32:30 2001 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.
* 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.
* configure.in: Add Cygwin case to set CCSHARED appropriately.
* Modules/Makefile.pre.in: Add autoconf variable SET_DLLLIBRARY.
* Modules/Makefile.pre.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 section to define extra libraries used
during the linking of shared extensions (currently only used
by Cygwin).
* Modules/makesetup: Add .def to the list of known file types.
* Modules/makesetup: Change shared extension rule to include
extra libraries (if any) during linking.
Is it undesirable to put platform specific code in makesetup?
* Modules/mmapmodule.c: Clean up to enable building as a Cygwin
(and Win32) shared extension.
* Modules/readline.c: Ditto.
* Modules/rotormodule.c: Ditto.
* Modules/shamodule.c: Ditto.
* Python/dynload_shlib.c: Add "module.dll" to the list of
Cygwin shared extensions; remove ".pyd".
Note that his change essentially backs out the fix for bug
#115973. Should ".pyd" be retained instead for posterity?
-------------------------------------------------------
Date: 2001-Jan-07 02:32
By: tim_one
Comment:
Yes, I told Jason (in email) I would agitate toward this end. At this
point it needs someone more familiar with the Unixish build process than I
am, though (haven't run a Unix box since '94, back when Python Unix config
wasn't hiding under umpteen layers of black magic ...).
-------------------------------------------------------
Date: 2001-Jan-06 16:20
By: nhv
Comment:
Any chance of getting this patch applied before the 2.1 release ?
-------------------------------------------------------
Date: 2001-Jan-05 10:52
By: tim_one
Comment:
Reassigned to Guido (sorry, Guido!). Here's the scoop: I have what
appears to be a clean Cygwin install on my box now, but, as with any new
build environment, it will take an unknown number of hours to work out its
quirks.
And I'll do that someday, but, frankly, it's irrelevant: this is no
different than a patch that purports to improve the build process on, say,
HP-UX. The author says it works, and while it would be *nice* to take the
time to confirm that, it's *essential* to confirm that it doesn't break the
build process on the systems we do use (I may build Python on Cygwim from
time to time someday because "it's nice to check it", but that's never
going to be a platform I routinely *use*).
Since the patch has no possible effect on the MS Windows build process (the
changes are entirely to the Unix build process), checking that it doesn't
break other builds is something a Unix guy has to do. Of course that "Unix
guy" doesn't need to be you -- but it sure isn't me.
-------------------------------------------------------
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.?
-------------------------------------------------------
Date: 2000-Nov-16 10:01
By: nhv
Comment:
Incorporating this patch will make Cygwin a much
nicer enviroment for Python development.
I have beta tested this and it works as advertised
for me :-)
-------------------------------------------------------
Date: 2000-Nov-27 13:27
By: gvanrossum
Comment:
Tim... Please give cygwin another try. Mail nhv or jlt63 for help if it
doesn't install properly for you -- they clearly are motivated to have this
added!
-------------------------------------------------------
Date: 2000-Nov-27 14:23
By: jlt63
Comment:
Tim, please feel free to contact me regarding any assistance that you may
need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm
willing to help in any way that I can.
-------------------------------------------------------
-------------------------------------------------------
For more info, visit:
http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470