[gdal-dev] Symbian Porting Issues

[Frank Warmerdam]

Mark Wilcox wrote:
> 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?

Mark,

I have no strong opinion on this.  I presume things work fine if the
internal gdal/frmts/zlib is used, right?

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

The addtiffo_src stuff is not used except by img2tif.  It should not be
included in normal GDAL builds.

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

I'm not sure I understand this issue.  If zlib.h defines WIN32 on a
platform that GDAL does not really consider WIN32 then I suppose we
ought to correct the definition right after including zlib.h everywhere
it is included (hopefully not too many places).

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

gdal/frmts/hfa/geoextra.c is not normally built into GDAL.  It is present only
for use with the img2tif utility.  I will take the liberty of clearing away
the img2tiff stuff which is no longer well maintained, and is not really used.

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

I'm ambivelent on this.  I think it is sufficient to conditionally compile
in an lfind() implementation for the Symbian and I wouldn't mind this
living somewhere appropriate in the GDAL tree (perhaps gdal/port).

Congratulations on the Symbian work.  Feel free to submit tickets with
suggested changes in support of the platform.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent