[SciPy-Dev] Release blocker?

[Charles R Harris]

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? I think the best
solution here would be to fix the build process.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20110216/88da3341/attachment.html>