[gdal-dev] ARM platform compatibility

[Even Rouault]

Hi Adriano,

Recently, I came through reading the http://wiki.debian.org/ArmEabiPort page 
and it appears that you must run a debian version with "old" ARM ABI, which 
has this weird byte ordering related to floating point emulation. The new ARM 
EABI of the armel architecture guarantees that floating point values use 
IEEE-754 representation, so GDAL should be happy with that architecture and 
consider it as standard little-endian host.

So I'd encourage you to test Lenny armel then, as I'm not sure we really want 
to hack GDAL in the many places where it is assumed that float and double 
values read from/written to the disk are IEEE-754 (module little endian/big 
endian ordering)... Shapefile driver is one of this instance, but there are 
many other GDAL raster drivers that should be patched too.


Le Tuesday 17 February 2009 05:22:34 Adriano C Naspolini, vous avez écrit :
> Hi Tom,
> I was trying with 1.5.3 (Debian etch, gcc-4.1), now changed to 1.6.0,
> but no success.
>
> About 1.5.2 version, didn't work neither.
>
> By default, configuration sets up "msb2lsb" (big-wordian). Forcing the
> configuration (changing configure file) to be "lsb2msb" make no
> difference (maybe because the problem is exactly there).
>
> The next step I'll do is to apply Etienne's patch manually, because it
> became incompatible with newer versions of shpopen.c...
>
>
> Thanks,
>
> Adriano
>
> Tom Kazimiers escreveu:
> > Hi Adriano,
> >
> > which version of CGAL did you compile for ARM?
> >
> > I use 1.5.2 and reading shapefiles works very well.
> >
> > Regards,
> > Tom
> >
> > Adriano C Naspolini schrieb:
> >> Hi,
> >> I developed an application and it runs perfectly over X86. However,
> >> when i try to run it on ARM it stops reading shapefiles (actually it
> >> reads wrong coordinates). I wrote a simple program to tell just the
> >> first "point" coordinates.
> >>
> >> On X86:
> >> x=: -53.1275 y= -31.8682
> >>
> >> On ARM:
> >> x=: -1.00226e-13 y= -1.76938e+52
> >>
> >>
> >> Looking for the problem here, i found a thread from Etienne Dube on
> >> (2004-04-07 05:12:55 GMT), saying it's a byte ordering problem.
> >> "Each 32-bit word in the 64-bit double value is stored little-endian,
> >> but the most significative 32-bit word comes last in memory
> >> ("big-wordian")."
> >>
> >> Changing the word-order for the first feature inside the ".shp" ("11
> >> 36 3c bd 52 90 4a c0" to "52 90 4a c0 11 36 3c bd") and running it
> >> again:
> >>
> >> under X86:
> >> x=: -1.00226e-13 y= -31.8682
> >>
> >> under ARM
> >> x=: -53.1275 y= -1.76938e+52
> >>
> >> So, clearly, i have the same problem then Etienne. He sent a patch,
> >> but didn't made many tests...
> >> Is there a "final"solution for the problem? I couldn't see any answer
> >> to him.
> >>
> >> Regards,
> >>
> >> Adriano
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev