[Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 24 Jan 2001 06:58:38 -0800
Patch #102409 has been updated.
Project: python
Category: Build
Status: Open
Submitted by: jlt63
Assigned to : akuchling
Summary: Cygwin Python DLL and Shared Extension Patch
Follow-Ups:
Date: 2001-Jan-24 06:58
By: jlt63
Comment:
> The setup.cfg file should be handling this... or does it do the wrong
thing somehow?
As you mentioned in a comment for the PEP 229 patch, setup.cfg is
hard-coding the installation directory at configure time to
"@prefix@/lib/python@VERSION@/lib-dynload".
Which means that "make prefix=/tmp/python/usr/local install" does not
work as expected. That is, everything except for the standard modules
install in "/tmp/python/usr/local" but the standard modules still end up
in
"/usr/local/lib/python2.1/lib-dynload". This makes it difficult to create
a
pre-built distribution.
Are you the right person to commit the Lib/distutils/command/build_ext.py
part? This is crucial to getting the Cygwin build working again.
It appears that the regen hunk of the Makefile.in part is no longer
necessary
since python seems to be setting sys.path correctly to find the standard
modules when running out of the build directory now.
BTW, setup.cfg.in is missed a NL at the end of the file.
-------------------------------------------------------
Date: 2001-Jan-23 19:31
By: akuchling
Comment:
Checked in the setup.py portion of this patch, modified to factor out
the getting of a platform value into a get_platform() method.
-------------------------------------------------------
Date: 2001-Jan-23 18:55
By: akuchling
Comment:
Looking at the Makefile.in part of this patch, why is the
--install-platlib
argument needed. The setup.cfg file should be handling this... or does it
do the wrong thing somehow?
-------------------------------------------------------
Date: 2001-Jan-19 22:31
By: jlt63
Comment:
This patch enables Cygwin Python to build using the new Distutils
style Python build. Please note that the build_ext.py part is from
Jorge Sousa <jsousa@cfn.ist.utl.pt>.
To patch, change directory to the top of the CVS tree and use
$ patch -p0 <dist.patch
The following is the ChangeLog:
Sat Jan 20 01:05:18 2001 Jason Tishler <jt@dothill.com>
* Makefile.in($(srcdir)/Lib/$(PLATDIR)): Add Distutils build library
directory to PYTHONPATH so regen works again.
(sharedinstall): Add --install-platlib option so shared extensions
follow $(exec_prefix).
* setup.py: Add checks for Cygwin so unsupported modules (i.e., dbm
and resource) are not built.
* Lib/distutils/command/build_ext.py(build_ext.finalize_options): Add
Cygwin specific code to append Python's library directory to the
extension's list of library directories.
(build_ext.get_libraries): Add Cygwin specific code to append Python's
(import) library to the extension's list of libraries.
-------------------------------------------------------
Date: 2001-Jan-19 08:19
By: gvanrossum
Comment:
Reopened at request. Don't sweat the release date -- t's only the first
alpha release. I have a feeling it'll be put off till Monday.
-------------------------------------------------------
Date: 2001-Jan-18 20:52
By: jlt63
Comment:
Please reopen because I need to redo the Cygwin build to handle the
use of distutils to build the standard extension modules instead of
Modules/Makefile.pre.in.
How much time (if any) do I have to resolve these issues before 2.1a is
released. I heard that the release date is tomorrow. Sigh...
-------------------------------------------------------
Date: 2001-Jan-10 19:39
By: jlt63
Comment:
Your welcome -- thanks for considering and accepting this patch.
If the patch proves to reek havoc on other platforms (most likely only
on NeXT, DG/UX, or BeOS), I am committed to help resolve the fall out.
-------------------------------------------------------
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