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, [email protected]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
