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 <[email protected]>
> To: Jeff Hamann <[email protected]>
> Cc: gdal-dev <[email protected]>
> 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
> [email protected]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
