[gdal-dev] KyngChaos Frameworks: GDAL's numpy vs Enthought's numpy

Jason Roberts jason.roberts at duke.edu
Mon Apr 19 11:50:22 EDT 2010

I recall a recent discussion regarding an "ABI breakage" with numpy 1.4.
Please see
Perhaps this could be the problem? The thread is very long and I did not
follow it to the end. 

> GDAL python *should* be able to use a later version of numpy than it was
built for, it's only the python side of the interface that it cares about

Yes, but GDAL's Python bindings access numpy's Python interface through C,
right? I presume the GDAL Python bindings include numpy.h. If so, then it
seems likely that a change to numpy's binary interface could result in an

I have not researched this fully. My apologies if I do not know what I'm
talking about here. My apologies if I'm starting a false rumor...


-----Original Message-----
From: gdal-dev-bounces at lists.osgeo.org
[mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of William Kyngesburye
Sent: Monday, April 19, 2010 11:30 AM
To: K.-Michael Aye
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] KyngChaos Frameworks: GDAL's numpy vs Enthought's

On Apr 19, 2010, at 8:51 AM, K.-Michael Aye wrote:

> Hi!
> I am using quite successfully KyngChaos' Frameworks for GDAL (Thank you,
William!) with a custom Python install from python.org on OSX. This install
already includes most of the stuff I need for my daily work
> But sometimes I need something special like mayavi2 and for that I have
installed the Enthought Python Distribution (luckily for free for academic
use), but I can't use the existing GDAL framework because it is based on
numpy 1.3 and not on numpy 1.4.
> If I try so, I get a weird 'Bus Error' message and Python just crashes.

GDAL python *should* be able to use a later version of numpy than it was
built for, it's only the python side of the interface that it cares about,
but I don't know what be happening at compile time that might lock it in to
a specific version of numpy, and python can be picky.

If you are including the GDAL framework python folder in the Enthought
python path, then numpy 1.3 is also available from there.  But depending on
how you added GDAL to the path, numpy might be overridden by Enthought's
path.  My installer puts a .pth file in the
/Library/Python/2.x/site-packages folder that forces it to the top of the
path.  A standard .pth (including the /Library site-packages), oddly, gets
added *after* the system paths, so they can't override the system modules.

> Am I guessing right, that the only remedy would be to build GDAL for Numpy
1.4 on my own?
> Or would it be more recommendable to find an old Enthought, that still
uses Numpy 1.3?

It's not [Enthought] python that's using numpy, it's GDAL and other python
programs.  As long as the python version matches, it should work, though
there can be other incompatibilities in different python builds.

> Then I should be able to import gdal into the Enthought's Python, right?
> Any advise would be appreciated!

I generally keep up to date, but I guess I don't check numpy very often and
didn't see the v1.4 (interesting, they skipped 1.4.0).  Though that is only
an RC release yet, so I may still wait for a final release.

You could try copying my gdal.pth to Enthought's user site-packages, so it
should override Enthought's numpy, but that will happen for all other python
usage iwth Enthought's python.

I just figured out that I could customize the GDAL python to force it to
load the framework copy of numpy, but I'd also then probably isolate that
numpy from the python path.  I may try that in the next release.

William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>

First Pogril: Why is life like sticking your head in a bucket filled with
hyena offal?
Second Pogril: I don't know.  Why IS life like sticking your head in a
bucket filled with hyena offal?
First Pogril: I don't know either.  Wretched, isn't it?

-HitchHiker's Guide to the Galaxy

gdal-dev mailing list
gdal-dev at lists.osgeo.org

More information about the gdal-dev mailing list