Building Cygwin-Python extension modules - export strategies

[Mark Hadfield]

Hello all

On Friday I posted a message entitled "Building Numeric package on
Cygwin-Python". I reported that the Numpy module library could not be built
with Cygwin Python 2.1 using the distutils-based setup script. With the help
of people who responded to this message, and to another one on the Cygwin
mailing list, I can now build Numpy. But to get it to work out-of-the-box
requires changes either to the C code or to distutils (see below). I would
like to trigger a discussion on this list and ultimately a ruling from the
Python gods (hello Tim!) about the one-true-Pythonic-way to write and
install Python extension modules for the Cygwin version of Python.

To recap, I have the Numpy source distribution, Numeric-20.0.0b2.tar.gz (but
I think these considerations apply to any Python module library that uses C
code) and I have Python 2.1 installed by Cygwin's setup program (but the
results should be the same if I had built it myself using the Cygwin gcc
compiler). I unpack the source and cd to the directory created. According to
the "Installing Python Modules" manual, I should be able to build & install
this by typing

    python setup.py build
    python setup.py install

However the build step fails at the first link command, with messages about
undefined symbols. The problem is (and I'm a bit hazy here) that to build a
DLL on the Windows platform, the compiler needs a list of symbols to be
exported. The above command invokes a Unix-like build process that doesn't
know about this.

There are two solutions:

1. (Thanks to Robert Yodlowski): In each C file foomodule.c, replace

    void initfoo ()

with

    DL_EXPORT(void) initfoo ()

where DL_EXPORT is a preprocessor macro.

2. (Thanks to Norman Vine): Invoke the setup script's "cygwin" compiler
option:

    python setup.py build compiler=cygwin
    python setup.py install

after first applying a patch (attached) that modifies a couple of distutils
files. The compiler then creates and uses the necessary .def files to
specify the exports. (Note that the Numeric source does include several .def
files but these are ignored.)

This is all fine, and it's not that much of a hardship to make one or other
of these changes. But obviously it would be good if Cygwin Python users
could build extension modules out-of-the-box, so I would like to see one of
these changes (or something like them) incorporated into Python and its
documentation. So which one? Jason Tishler and Norman Vine have told me that
these things have been discussed before on python-dev and distutils-sig but
never carried through to a resolution

Option 1 does have the blessing of Tim Peters

    http://mail.python.org/pipermail/python-dev/2001-February/013292.html

The downside is that it requires changes (albeit minor) to the C code of the
Numeric package and, I presume, most other Python extension packages. Not to
mention modifications to the "Extending and Embedding" manual.

Option 2 was raised by Jason Tishler on distutils-sig

    http://mail.python.org/pipermail/distutils-sig/2001-February/002003.html

but there wasn't any enthusiasm for it so he dropped it (to paraphrase
Jason's words). If this is to be applied I would prefer that it not be
necessary to specify the "cygwin" compiler option explicitly. (According to
the "Installing Python Modules" manual this should only be necessary when
using Cygwin to build extensions for native win32 Python.) Yes, I know I can
achieve this myself via the distutils configuration file.

Jason has told me that he prefers Option 1. Perhaps he would like to explain
why. Since Jason is the Cygwin Python demi-god and Tim Peters is ...well...
Tim, the score is currently 1.5-to-0 in favour of Option 1. I favour Option
2 because it doesn't require any source code changes, but my ranking on the
Python-god scale is zero. But lets talk about this and tease out any more
pros and cons.

---
Mark Hadfield
m.hadfield at niwa.cri.nz  http://katipo.niwa.cri.nz/~hadfield
National Institute for Water and Atmospheric Research
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diffs
Type: application/octet-stream
Size: 1371 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20010430/44ee6c37/attachment.obj>