[Gdal-dev] status of ldshared build? (or, other options for OSX framework build)

[Christopher Barker]

William Kyngesburye wrote:
>  The future 
> directions page on the libtool site doesn't mention anything about 
> frameworks.

Oh well, I guess we need to just live with what's there.

> Exactly.  Libtool builds it as
> 
> /Library/Frameworks/GDAL.framework/Versions/1.5/libgdal.1.dylib
> 
> Before installation, python links to that.  Then the GDAL install 
> renames it to
> 
> /Library/Frameworks/GDAL.framework/Versions/1.5/GDAL
> 
> and needs to tell the gdal python libs the same (install_name_tool).

Ah -- here is the issue, which again, seems to be caused by the fact 
that we are installing GDAL AFTER building the python extension. 
Otherwise the name would have changed before the python ext. was linked.

Could you run re-name libgdal.1.dylib to GDAL after building, rather on 
installation?

But to avoid that, you wan to use:

install_name_tool -change to change the name of the lib that the python 
extension is already linked to? In which case, I think something like 
this would work:

install_name_tool -change \
/Library/Frameworks/GDAL.framework/Versions/1.5/libgdal.1.dylib \
/Library/Frameworks/GDAL.framework/Versions/1.5/GDAL \
swig/python/build/lib.macosx-10.3-fat-2.5/osgeo/_gdal.so

after "setup.py build", and before "setup.py install"

Except that the ".macosx-10.3-fat-2.5" will change depending on what 
system/python it's being built on, but it looks like there is a way to 
ask python about that:

 >>> "-".join( (distutils.util.get_platform(), sys.version.split()[0]) )
'macosx-10.3-fat-2.5'

though you'd think there'd be an easier way!


This sure feels uglier than just building the python bindings after 
installing the GDAL framework! Or am I repeating myself here....

>> I know it's kludgy, but couldn't we put yet another link in to what 
>> python is looking for? The right way, I suppose, is to get it to look in:

now that I see what you're doing, I guess I'd keep the original name, 
and add a link to "GDAL", rather than re-naming it.

> As you say, kludgy.  And messy.  I want to get it right.

maybe, but all this re-naming feels pretty messy (and fragile) too!

> All OSX libraries embed the full path to theirselves.  The linker then 
> embeds that into other libraries that link to them.

Wow! such dependence on paths not changing! Though I suppose that solves 
the version issue -- you could have ten versions of a lib installed in 
ten places!

And it means you need to know at build time where you're going to 
install something (or get these problems!) which makes me think -- is 
there a way to specify the install path when the lib is built? rather 
than re-naming it later with install_name_tool?


> This is a possibility, even in the current build-everything context.  It 
> just needs a another flag: -F../.., and the framework would have to be 
> assembled in the source tree first.  hmmm.....

That may be an option too -- and a bit cleaner than what we figured out 
above.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov