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

[Ivan Lucena]

Hi guys,

Sorry to interrupt but I was having the exact same error as Jeff and I was following the discussion quite close.

But I found a solution. I can get it to work as long as if I use python2.6:

turtlebowl:~ ilucena$ python2.6
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from osgeo import gdal
>>> drv = gdal.GetDriverByName("GTIFF")
>>> print drv
<osgeo.gdal.Driver; proxy of <Swig Object of type 'GDALDriverShadow *' at 0x1002596a0> >
>>> ^D

But if I use the default python,  2.7 - that I download binaries from python.org and run the installer from the dmg, 
that is what I got:

turtlebowl:~ ilucena$ python
Python 2.7 (r27:82508, Jul  3 2010, 20:17:05) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from osgeo import gdal
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osgeo/__init__.py", line 21, 
in <module>
    _gdal = swig_import_helper()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osgeo/__init__.py", line 17, 
in swig_import_helper
    _mod = imp.load_module('_gdal', fp, pathname, description)
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osgeo/_gdal.so, 
2): Symbol not found: _CPLDefaultErrorHandler
  Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osgeo/_gdal.so
  Expected in: dynamic lookup

Just like Jeff.

This is my system:

turtlebowl:~ ilucena$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.6.4
BuildVersion:	10F2061

I build GDAL with and without macosx-framework that doesn't seem to affect.

So, what does it means? 

Regards,

Ivan

>  -------Original Message-------
>  From: William Kyngesburye <woklist at kyngchaos.com>
>  To: Jeff Hamann <jeff.hamann at forestinformatics.com>
>  Cc: gdal-dev <gdal-dev at lists.osgeo.org>
>  Subject: Re: [gdal-dev] can't import osgeo or gdal in python
>  Sent: Sep 20 '10 15:15
>  
>  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.
>  
>  
>  _______________________________________________
>  gdal-dev mailing list
>  gdal-dev at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/gdal-dev
>