Creating C modules for Python under Cygwin

[Neil Hodgson]

Martin v. Löwis:

> 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. I thought this was
> overstated, but didn't dare question the "common knowledge" that you
> can only link against DLLs, not executables.

   While you can link against executables, you should avoid doing so in most
cases. The common case where this occurs is where a DLL is mostly a library
that provides services consumed by the executable but a need appears for a
call back into the executable. You then have two binaries which depend on
each others export libraries to link. To resolve the mutual dependence, a
clean build needs to link one side twice, the first time with /FORCE (which
ignores undefined symbol errors caused by the lack of an export library) so
you get a valid export library, then build the other side against that
export library, then rebuild the first side against the now-existing export
library. Often future builds will work without /FORCE even with the API
changing as one side will be satisfied by an old export library. This can
cause "it builds on my machine but not on theirs" problems unless you think
through the make and/or project files.

   Its simpler to use function pointers or vtable analogues for this
situation.

> I wonder what those "other reasons" could be, though. What exactly
> *is* the rationale for Python using a DLL on Windows?

   COM. If you want to use COM objects implemented in Python in-process from
arbitrary executables such as IIS or IE, then you can't require linking to
another  executable.

   Neil