[Gdal-dev] Universal GDAL build on OS-X ??

[William Kyngesburye]

On Oct 29, 2007, at 6:41 PM, Christopher Barker wrote:

> William et al,
>
> NOTE: This is all SVN trunk, on OS-X 10.4.10
>
> I've got close!
>
> It looks like I have GDAL building Universally, and the python  
> bindings building, but something went wrong in the install stage. It  
> looks like I've got the Framework mostly OK, but when I try to  
> import geos.gdal, I get:
>
> ImportError: dlopen(/Users/cbarker/.python-eggs/GDAL_OGR-1.5.0-py2.5- 
> macosx-10.3-fat.egg-tmp/osgeo/_gdal.so, 2): Library not loaded: / 
> Library/Frameworks/GDAL.framework/Versions/1.5/libgdal.1.dylib
> Referenced from: /Users/cbarker/.python-eggs/GDAL_OGR-1.5.0-py2.5- 
> macosx-10.3-fat.egg-tmp/osgeo/_gdal.so
> Reason: image not found
>
> indeed, there is no:
> /Library/Frameworks/GDAL.framework/Versions/1.5/libgdal.1.dylib
>
> but there is a:
>
> /Library/Frameworks/GDAL.framework/Versions/1.5/GDAL
>
> and a:
>
> /Library/Frameworks/GDAL.framework/Versions/1.5/unix/lib/libgdal.dylib
>
> which is a link to the "GDAL" file above.
>
> I made another link to it:
>
> $ ln -s GDAL libgdal.1.dylib
>
> and now osgeo.gdal imports OK -- I've yet to test.
>
Right.  Known problem.  I mentioned it to Frank, but didn't do a bug  
report yet.  The problem is that the framework build does its stuff  
during install because currently libtool can directly make "GDAL" as  
the libname but must create "libgdal.dylib".  So install_name_tool is  
used during install.

But, the path to the ng python install is not known to the GDAL  
makefiles, that is handled by distutils/setuptools, so it can't run  
install_name_tool on it.

I can hack libtool to do it right, but I don't know if it's possible  
to configure libtool to do it right.

The other possibility is some other option to distutils/setuptools to  
completely override the python install path, then install_name_tool  
could be used.

I'm waiting on some decision about where to install the python  
extensions - the system path (the problem would remain), or alongside  
GDAL (can use install_name_tool).

Or maybe there is something that can be done in the makefile to  
determine the python install path?


> A few other questions:
>
> The utilities are getting put in:
>
> /Library/Frameworks/GDAL.framework/Versions/1.5/Programs
>
> Is that the Apple standard? Should/could there be symlinks in /usr/ 
> local/bin also? I hate adding all that stuff to my $PATH.
>
It's really my standard, to keep the whole package selfcontained.   
With my binary release I do include a script to create symlinks in / 
usr/local/bin.  But I'm not a unix stickler like some, so I don't mind  
having a long PATH.

The unix symlinks are also my stuff - I call it the "unix  
compatibility" part.  So the frameworks can easily be used in packages  
that don't know about frameworks.

>

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

[Trillian]  What are you supposed to do WITH a maniacally depressed  
robot?

[Marvin]  You think you have problems?  What are you supposed to do if  
you ARE a maniacally depressed robot?  No, don't try and answer, I'm  
50,000 times more intelligent than you and even I don't know the  
answer...

- HitchHiker's Guide to the Galaxy


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

[Trillian]  What are you supposed to do WITH a maniacally depressed  
robot?

[Marvin]  You think you have problems?  What are you supposed to do if  
you ARE a maniacally depressed robot?  No, don't try and answer, I'm  
50,000 times more intelligent than you and even I don't know the  
answer...

- HitchHiker's Guide to the Galaxy