[Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now

[Amaury Forgeot d'Arc]

Hello,

On Wed, Jan 21, 2009 at 22:07, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> On Wed, Jan 21, 2009 at 7:42 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>>>  sorry, martin - i thought the win32 builds generated python25.lib,
>>> python25.dll
>>
>> Correct.
>>
>>> and python25.def
>>
>> No.
>>
>>> so as to fit into the 8.3 filename convention.
>>
>> No. It generates python25.lib because that's the import library
>> for python25.dll. It calls it python25.dll because the lib prefix
>> is atypical for the platform, and also redundant (DLL means
>> "dynamic link library").
>>
>> The Python binary installer also includes libpython25.a, for use
>> with mingw32.
>
>  ok, so - different from what's being generated by ./configure under
> msys under wine or native win32 - what's being generated (libpython 2
> . 5 . a and libpython 2 . 5 . dll . a) is more akin to the cygwin
> environment.
>
> therefore, there's absolutely no doubt that the two are completely different.
>
> and on that basis, would i be correct in thinking that you _can't_ go
> linking or building modules or any python win32 code for one and have
> a hope in hell of using it on the other, and that you would _have_ to
> rebuild e.g. numpy for use with a mingw32-msys-built version of
> python?
>
> or, is the .pyd loading a bit cleverer (or perhaps a bit less
> cleverer) than i'm expecting it to be?

On Windows, you must turn on the --enable_shared option if you want to
build extension modules.
You could take the cygwin build as an example, see what's done in
./configure.in.

-- 
Amaury Forgeot d'Arc