[gdal-dev] can't import osgeo or gdal in python

[William Kyngesburye]

On Sep 20, 2010, at 12:33 PM, Christopher Barker wrote:

> Jeff Hamann wrote:
>> Chris, Thanks for responding to my post. 
> 
> re-including the gdal list -- I suspect you didn't mean to reply only to me.
> 
>> I'm not using the pre-built frameworks as I'm trying to construct a stack that can be "easily" built, installed, and replicated on Linux, FreeBSD (my fav), windows (not so much) and OSX.
> 
> In that case, I'd forget about the framework build -- you might as well keep it as similar to the other *nix's
> 
Well, on its own, the framework build of GDAL is just as easy to built and install as the unix-style library build, and could be also considered standard.

As a stack, I like to think my frameworks and packages are a de facto standard, though I don't promote that as much as I should.  There are build scripts for all but GDAL (maybe I'll clean that one up someday, but it's not a high priority since the GDAL source has a framework option), so it's easily replicated.

>>>> When I try to "run" (again newbie
>>>> talking here, so be patient), a python script and import gdal:
> 
>>>> /Library/Python/2.6/site-packages/GDAL-1.7.2-py2.6-macosx-10.6-universal.egg/osgeo/_gdal.so
>>>> Expected in: flat namespace
> 
> This is something I know next to nothign abuot, but I know there is something in OS-X with things being build with either "flat" or "nested" namespaces -- perhaps those have gotten confused with your build? Did you build your own Python?

flat/two-level namespaces are a way to internally organize the external library functions ("symbols") used by a library or program.  With flat (linux-like), the library name is not recorded, so it looks in each loaded library for the function, which can be slow.  With two-level, the library name is stored along with the function name, so it only needs to look in that library.

When a function is not found, with a flat namespace the error can't tell you where it was expecting to find it  But with a two-level namespace, the error can tell you the library name, which helps figure out where the problem is.

So, your error only means it can find CPLDefaultErrorHandler(), but it doesn't know where it's supposed to be.  The flat namespace isn't necessarily the source of the problem (though it can lead to problems finding symbols that are loaded).

The default in recent versions of the OSX development tools is two-level.  It has changed a couple times in the past.  In the early porting days one or the other has had problems with *nix ports, and developers have tried to hardwire into configure whichever one seemed to work for them (usually that meant forcing flat namespaces).  These days namespace issues have been worked out and the default two-level works just fine.

Sorry for the long-winded explanation.

... hmm, looking at the GDAL configure, I see that for OS X 10.5 and 10.6 it does not add the flat-namespace option to the GDAL library linking, but it does for earlier versions (at least it looks like it does).  Are you setting MACOSX_DEPLOYMENT_TARGET before configuring?

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.