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

[Christopher Barker]

William Kyngesburye wrote:
>> It sounds likethe OS-X port of libtool is broken and/or incomplete -- 
>> are the libtool developers open to fixing this kind of stuff?

> Libtool is not "broken", it just doesn't have the ability to directly 
> create a binary of the framework style

I did say "or incomplete". Anyway, my point was that, according to the 
libtool web page, the goal of libtool is to provide one interface to 
building and installing shared libs. IN order to support OS-X, it should 
be able to build standard Frameworks, so I was wondering if the libtool 
devs are open to adding this functionality.

My other question is: are you trying to build what Apple could consider 
a "standard" framework, or something that's a mixture of regular old 
libs and a Framework?

> So the 
> current GDAL makefile lets libtool do its thing, then renames it and 
> changes its internal link path during installation.

OK, so I'm still confused as to why you need to hand-alter (or makefile 
alter) anything in the python package -- aren't all the changes needed 
in the GDAL Framework?

In my case, it looked like the python extension was looking for:

/Library/Frameworks/GDAL.framework/Versions/1.5/libgdal.1.dylib

where there already is:
/Library/Frameworks/GDAL.framework/Versions/1.5/GDAL
and:
/Library/Frameworks/GDAL.framework/Versions/1.5/unix/lib/libgdal.dylib

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:

/Library/Frameworks/GDAL.framework/Versions/1.5/unix/lib/

But I'm still confused as to how that path is being set.

Maybe this is it, from setup.py:

     libraries = ['gdal']
     library_dirs = ['../../.libs','../..']
     extra_link_args = []

That's how it finds the libs when it's building, but how does it know to 
look in the Framework when installed?

>> build GDAL
>> install GDAL lib (framework on OS-X)
>> build python extensions (using installed GDAL)
>> install python extensions
>>
>> would that work better?

> Yes, that is a possibility.  But the current GDAL python setup.py 
> doesn't work that way - it looks for the source-built copy of libgdal.

This just seems odd to me, and I'm surprised it isn't causing problems 
on other platforms. I guess it comes down to the idea of what are shared 
libs for? I think they are for, well, sharing the same libs among 
various programs, in this case, the various gdal utilities, anything 
built to use gdal, and the various language extensions.

In this case, it seems the normal route is to install the shared libs, 
then build the stuff that depends on them. I think that would work 
better in this case, and I think all it would take to build that way is 
to put something in the setup.py like:

extra_link_args=['-framework', 'GDAL']

I'll poke into this some more, if you like.


>> >>> distutils.sysconfig.get_python_lib()
>> '/usr/lib/python2.5/site-packages'
>>
> That's a good possibility, and what I was looking for.  I'm just not up 
> to speed yet on Python ;)

It took me a while to find it.

-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