[SciPy-Dev] Release blocker?

[Robert Kern]

On Wed, Feb 16, 2011 at 18:04, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
> On Wed, Feb 16, 2011 at 4:53 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>> On Wed, Feb 16, 2011 at 17:23, Pauli Virtanen <pav at iki.fi> wrote:
>>
>> > I managed to reproduce the issue by building Scipy with Mingw against
>> > the
>> > official Numpy 1.5.1 binary, so at least that sort of build setup
>> > appears
>> > to produce strange binaries. The build is driven by distutils, so I've
>> > little idea what's happening in it. This might be some sort of Mingw
>> > problem.
>> >
>> > So at least two solutions seem possible: (i) apply the patches from my
>> > github branch to replace malloc/free by static allocations, or
>> > (ii) fix the build setup.
>>
>> You should never use raw malloc/free in C extensions, but you don't
>> have to rely on static allocations. Always use
>> PyMem_Malloc/PyMem_Free. This will make sure that everything uses the
>> C runtime that Python was built with regardless of what CRT is
>> available at build time for the extension.
>>
>> http://docs.python.org/c-api/memory.html#memory-interface
>>
>> That said, distutils should already be passing the right flags to
>> mingw to link against msvcr90.dll unless if we are interfering. Can
>> you show us the command lines that are being executed on your machine?
>> I believe that using the environment variable DISTUTILS_DEBUG=1 will
>> cause setup.py to print them out as it goes along.
>
> Hmm, numpy uses malloc/free in some places. Would this also be a problem
> with the private memory management in the refactor branch?

Yes. At least it's centralized to one place that needs to be
configured/fixed. It should at least be possible to make npy_malloc()
use PyMem_Malloc() when libndarray is being built for numpy itself.

Grepping the numpy source, I see we have a few uses of raw malloc().
numpy already tries to do the right thing by providing a
PyArray_malloc() macro (_pya_malloc(), internally).

> I think the best
> solution here would be to fix the build process.

We need to do both.

-- 
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