John Hunter wrote:
"Todd" == Todd Miller <jmiller@...86...> writes:
> Either an extension in your application forgot to call
> import_libnumarray() or the numarray distributed as part of
> your application is incomplete or broken and the import
> failed. numarray CVS now makes a better report of which is
Could that someone be us?
I don't think so. For matplotlib we use import_array() because that's the init call for numarray's Numeric compatible interface. I think Tim's import_libnumarray() message is originating from numarray as it tries to call it's own API, most likely because the numarray installation is broken so the import failed.
Here's a couple other facts:
1. The import_libnumarray() message is confusing because I didn't think numarray import failures would occur in a sane world... so import failures in numarray-1.3.3 look the same as uninitialized extensions.
2. numarray uses it's own API to share code internally, so when numarray's rather complex import fails, the first internal call to it's own API generates the cryptic fatal error.
numarray CVS does two new things that are about a week old:
1. It correctly reports numarray's own import failure with a fatal error. This should clarify future problems if there are any.
2. Explicit imports of core extensions were added to numarray.__init__ so that py2exe can figure out what extensions must be included in an installer. This should actually solve the problem.
Those fixes address "exactly the same symptoms" (py2exe + cryptic fatal unitialized API error message) seen by another user who tested the fix on two different installer tools.
> grep -ri import_libnumarray .
in my src tree and got zippo.
Is this a matplotlib bug. If so, I'll be happy to patch it and roll
out a bug-fix release.
Nope, don't think so.