[gdal-dev] Symbian Porting Issues

[Mark Wilcox]

Hi,

First off, I must congratulate Frank and all the GDAL contributors on producing a fantastically portable library!  With just 2 days of effort starting from basically zero knowledge of GDAL I've got the core running and many of the raster formats building for Symbian OS.  I've even tested JPEGs and GeoTIFFs with a simple viewer application in the Symbian emulator.

A lot of tidying and testing is still required plus the vector formats for OGR (although the core OGR functionality is building already) and maybe the utilities and python bindings.  I took a look at the code and decided the fastest approach would probably be to try to build everything directory by directory, excluding things with external dependencies and non-trivial errors for future examination.  As such I'm probably building some things I shouldn't be but I'll look at a proper configuration once I've got my new laptop setup to dual-boot Linux with Vista (I'm much more familiar with the Linux build environment, despite being forced to use Windows for Symbian stuff at the moment).

Python is available on Symbian and Nokia have just released a new version (upgrading to 2.5.2 from 2.2) so I'll look and see if it's feasible to build and run the autotest stuff too as soon as I have time - is there much C/C++ test code other than that though?

Most of the issues I came across were related to the Nokia compiler (ex-Metrowerks) for the windows emulator environment being more fussy about implicit casts than anything else GDAL is built with.  However, in the process of porting I've come across some issues that may be worth further investigation by those more knowledgeable about the code base:

1) For some reason inflateCopy() is missing from the Symbian zlib port, even though it claims to be version 1.2.3 (existing library shipped in device firmware, not the internal copy in GDAL) at the moment I'm just excluding cpl_vsil_gzip.cpp from my build.  I'll try to get Nokia/Symbian to fix this and include the function in future releases.  I've seen some archive post that suggests maybe the same functionality could have been achieved without this dependency to support older versions of zlib though... is it worth reconsidering that option for Symbian support or is the gzip support not so commonly used?

2) /frmts/hfa/addtiffo_src/rawblockedimage.cpp contains:
#ifndef _WIN32
#  include <unistd.h>
#endif
should this be #ifndef WIN32 or possibly better yet #ifdef HAVE_UNISTD_H?
Currently the build will fail for a Symbian emulator because _WIN32 is defined but you're effectively cross-compiling to an odd hybrid environment.

3) The zlib library also uses a WIN32 define for portablility, this caused clashes in several places which I've temporarily fixed by changing the order of the includes (so that zlib.h comes after any gdal headers).  This is very unsatisfactory but I'm not sure what the real solution is.  One option would be to get the Symbian port of zlib fixed so it doesn't export this definition to the world in it's public header, another would be to change the cpl_port.h to undef WIN32 before re-checking for itself.  I thought possibly the latter since zlib isn't updated so often?


4) There are a couple of symbol clashes at link time between /frmts/hfa/geoextra.c & /frmts/gtiff/libgeotiff/geo_extra.c.  I assume that one of them is not normally built?  I've excluded the hfa version from the build for now but is there a case for removing one permanently, or moving the functions to a common location shared by both drivers?  The implementations are slightly different.

5) Symbian doesn't have an lfind() implementation at the moment.  I've borrowed the one from the full version of libtiff's port directory but wondered if there might be a case for including a version more permanently in GDAL, either with the internal copy of libtiff or perhaps in the porting layer?

Does anyone have any comments or suggestions on any of the above issues?

Does anyone have any experience using the autotest in a cross-compilation environment? (Maybe I need to talk to Mateusz about that?)

Apologies for the long mail.

Best regards,
Mark


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090105/0a4f6691/attachment.html