[gdal-dev] GDAL 1.5.0 Beta2 Released

[William Kyngesburye]

On Dec 11, 2007, at 2:49 PM, Christopher Barker wrote:

>> I went the route of building explicitly and  separately for each  
>> system version.
> > It's easier to compile that way,  and to install.
>
> well, yes and no. If you are building a 10.4 (I get confused as to  
> which cat is older than which -- at least Ubuntu puts their animals  
> in alphabetical order!) compatible version, then a 10.5 one is just  
> extra work -- which is fine if you are doing it!
>
The problem is the new 64bit stuff in leopard.  I first started with  
one build for Tiger & Leopard.  This is a lot of work - build 32bit  
universal with the 10.4 SDK, build 64bit universal with the 10.5 SDK,  
lipo the two together for a quad-arch binary (and make sure I don't  
miss any in a complex package).

Then, on install, for Tiger strip out the 64bit parts.  I found a  
annoying trap on Tiger - it has limited 64bit support (but not enough  
for GDAL and most of the other frameworks), and will try to run 64bit  
binaries on 64bit processors, which will usually fail.

>> I'm not sure what the problem is with Leopard's Python, if any.
>
> Partly it depends on how you want to use it. For one, I often need  
> to build py2app's bundles for re-distribution -- if I use the 10.4  
> Universal Framework build, then I cover a lot of bases.
>
Which I can't do, because I build separately for each platform.  But,  
the binaries can be linked to in other software however is desired -  
ie link to the Leopard framework binaries with the 10.4 SDK, run on  
Tiger (with the Tiger framework binaries installed).

>> There was some debate about it on the python list, but I don't  
>> remember any serious real issues (but then, a lot of the extensions  
>> that were discussed aren't of interest to me).
>
> Well, these are the ones I know of:
>
> - no readline
>
But does use libedit.

> - weird mixture of 32/64 bit quad libs and 32bit libs (though I  
> don't think that breaks anything)
>
A lack of 64bit carbon.  Which is probably why Apple made the Python  
executable 32bit-only.

I actually build my GDAL Python bindings 64bit-enabled.  But since the  
python executable is only 32bit, gdal python will only run 32bit,  
unless someone has a 64bit python executable.  I'm planning on looking  
into compiling just the python executable 64bits to match Apple's and  
run the GDAL autotests with that - as long as nothing tries to load a  
python extension that needs carbon (nothing in GDAL), it should work.

Sadly, the python GUI stuff uses carbon.

>>
>> I guess I'll see what happens when I try the GRASS python GUI on  
>> Leopard...
>
> yup.
>
> Anyway, If you're going to do anything -- please support the 10.4  
> python. Beyond that, anything else you do is gravy -- and believe  
> me, I appreciate it all.
>
The Tiger bindings should work off a Leopard GDAL framework - the  
system version compatibility issue has nothing to do with the GDAL  
API.  If you're willing to try I can make a GDAL Python standalone  
installer that will install the Tiger bindings on Leopard...

>> Actually, the windows eggs DO need an external gdal.
>
> hmm, that's unfortunate -- again -- it makes me want a Linux style  
> package manager!
>
I think this applies to all platforms for GDAL.  It's just the way the  
GDAL bindings work.

>

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

The equator is so long, it could encircle the earth completely once.