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

[William Kyngesburye]

On Nov 2, 2007, at 2:42 PM, Christopher Barker wrote:

> 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.
>
I don't follow libtool development.  Since OSX has been around for a  
while, and libtool has been thru many versions since, and I don't see  
support in the 2.x development, I doubt it will happen.  The future  
directions page on the libtool site doesn't mention anything about  
frameworks.

> 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?
>
The end product is a normal framework.  But even Apple uses the  
"mixed" type - see the OpenGL framework, which includes libGL and  
libGLU as separate library files.  But they don't recommend others  
doing that (though I did for a while).

>> 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
>
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).

The unix/ stuff is just a convenience for other unix software that  
doesn't know about "-framework GDAL".

> 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/
>
As you say, kludgy.  And messy.  I want to get it right.

> 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?
>
All OSX libraries embed the full path to theirselves.  The linker then  
embeds that into other libraries that link to them.  You can see this  
with:

otool -L /path/to/some/library/or/program


>>> 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.
>
It's an OSX problem, just for the framework build.  If you build GDAL  
as a dylib on OSX (which is exactly what the framework build does,  
really), and install in some standard location like /usr/local, the  
python linking won't have this problem.  But then you don't have the  
nice packaged framework that is so much easier to install and  
uninstall than the library.

> 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.

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.....


-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the  
past isn't a fiction designed to account for the discrepancy between  
my immediate physical sensations and my state of mind?"

- The Ruler of the Universe