Creating C modules for Python under Cygwin

[Philip Swartzleonard]

Alex Martelli || Sun 05 May 2002 11:13:48a:

> 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. I thought this was
>> overstated, but didn't dare question the "common knowledge" that you
>> can only link against DLLs, not executables.
> 
> I'm not sure what Cygwin or other versions of gcc for Windows can do.
> With Microsoft Visual C++, the "common knowledge" is however 
misplaced.
> 
> 
>>> I really can't see that.  A standalone python.exe might be less than
>>> optimal for other reasons
>> 
>> I wonder what those "other reasons" could be, though. What exactly
>> *is* the rationale for Python using a DLL on Windows?
> 
> A typical example of "a good reason to keep Python in a DLL" would be
> if several different applications (.EXE's), not just Python.exe,
> embedded Python.  With Python in a shared library, every extension
> can be linked just once, against the DLL, and will be usable with any
> application that embeds Python through that DLL.  If extensions were
> linked against Python.EXE, they'd have to be relinked separately for
> every embedding-application that wants to have those extensions
> available.
> 
> I don't know if there are all that many .EXE's embedding Python on
> Windows, nor if that was the reason for the (perfectly reasonable)
> choice to build Python itself as a DLL there.  Just expounding on the
> "less than optimal for other reasons" comment I made above -- I
> realize not everybody's been "blessed" with doing systems-level
> development and consulting on Windows for many years (how I pity you
> all poor, deprived developers who had to stick to Linux, BSD, &c...!),
> so these tradeoffs may be not clear at all to many readers, since they
> _are_ quite different from those involved with .so's on Linux &c.

Hm, what's the effective difference between embedding the dll in a 
program (static linking?), and just sticking it in alongside, like my 
bootstraping execframe* does. I mean, i'm using McInstaller for this, so 
it compresses the DLL and unzips it before running. I can't think of any 
real differences between these methods of distrubution, really...

And-i'm-annoyingly-tuned-to-windows-too-ly yrz =)

-- 
Philip Sw "Starweaver" [rasx] :: www.rubydragon.com