G?za> Is there any other solution better then modifying two
G?za> modules of separate packages?
Probably not -- numpy should probably remove this -- you might want to
email their list.
JDH
G?za> Is there any other solution better then modifying two
G?za> modules of separate packages?
Probably not -- numpy should probably remove this -- you might want to
email their list.
JDH
John Hunter wrote:
"Géza" == Géza Groma <groma@...1111...> writes:
> Is there any other solution better then modifying two
> modules of separate packages?Probably not -- numpy should probably remove this -- you might want to
email their list.
Building extensions for 2.4 with Mingw is not 100% reliable no matter how it's
done. Mingw has been written to use MSVCRT.dll as its C runtime. Python 2.4 uses
MSVCR71.dll as its C runtime. If you leave out the 'msvcr71' library and use an
out-of-box Mingw installation, then you will get two different C runtimes. If a
FILE pointer passes between them (or any other structure provided by the C
runtime), you will crash the interpreter. However, the headers for Mingw have
been written against MSVCRT.dll and reference things not present in MSVCR71.dll
(in this case _ctype, a jump table used by isalpha() and friends IIRC).
There is currently no general solution that will work for all extensions. The
only general solution is to modify Mingw to use MSVCR71.dll as its runtime. But
no one seems to be working on that.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco