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
