Creating C modules for Python under Cygwin

Jason Tishler jason at tishler.net
Mon May 6 09:17:44 EDT 2002


On Sun, May 05, 2002 at 06:49:21PM +0200, Martin v. Löwis wrote:
> Alex Martelli <aleax at aleax.it> writes:
> 
> > So, it's PERFECTLY feasible on Windows for a DLL to access symbols that
> > are defined in the executable that loads said DLL, by any of several
> > means.
> 
> That's very interesting indeed. In http://python.org/sf/551093, Jason
> Tischler argues that you absolutely must build Python with a shared
> Python DLL, or else it can't possibly work.

In the above URL, I stated that linking shared extensions against a
static Python library does not work under Cygwin.  At least that was
my intention -- sorry, if I was unclear.

If you try using a static Cygwin Python library, then you will get the
following results:

    $ ./python     
    Python 2.3a0 (#2, May  5 2002, 21:24:59) 
    [GCC 2.95.3-5 (cygwin special)] on cygwin
    Type "help", "copyright", "credits" or "license" for more information.
    Fatal Python error: Interpreter not initialized (version mismatch?)
    Aborted (core dumped)

I got the above or similar results when I first tried to get shared
extensions to work under Cygwin about 2 years ago.  So, I decided to
use a shared (i.e., DLL) Cygwin Python library for the following reasons:

    1. Win32 Python used a DLL Python library too
    2. DLLs appear to be en vogue on Windows (and Cygwin)
    3. shared extensions worked!

I guess that #3 is the most compelling. :,)

Some of Alex's posts in this thread and my knowledge of the Cygwin
PostgreSQL build gave me an idea of how to (quick and dirty) create an
import library for python.exe with a static Python library:

    $ configure --disable-shared
    $ make # [1]

    $ dlltool --export-all --output-def python2.3.def python.exe
    $ dlltool --dllname python.exe --def python2.3.def --output-lib libpython2.3.dll.a

    $ make # [2]

Note:

    [1] make will fail building all shared extensions with many
        unresolved _imp__* references due to a compiling for an import
        library but linking against a static one.
    [2] make succeeds this time because we are linking against an import
        library now.

Unfortunately, the shared extensions created this way do not work even
though they build cleanly:

    $ ./python
    Python 2.3a0 (#1, May  6 2002, 07:10:16) 
    [GCC 2.95.3-5 (cygwin special)] on cygwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import _socket
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ImportError: dlopen: Win32 error 193

    $ fgrep 193 /usr/include/w32api/winerror.h 
    #define ERROR_BAD_EXE_FORMAT 193L

Does anyone know how to build Cygwin Python shared extensions when built
with a static Python library?  If so, then I will submit a patch to the
Python patch collector to clean up the --disable-shared build.

Note that you can currently configure Cygwin Python with --disable-shared,
but to be successful *all* extension modules must be static.

> I thought this was overstated, [snip]

Please feel free to question any of my statements.

Jason






More information about the Python-list mailing list