Thanks again for your help Frank. As usual, you were spot on and adding the following line to .../port/cpl_config.h.in before building fixed the problem:
#define HAVE_LONG_LONG 1 I've now added this to my own build notes. Since the problem didn't occur when using the beta versions of Apple's Xcode 5 and only occurred with the final version of Xcode 5, I'm assuming that Apple changed their developer tools/environment with their production release which coincided with their announcement of 64-bit iPhones (iPhone 5S) in such a way that it affected what 'configure' wrote to cpl_config.h. Cheers, Nik. On 27/09/2013, at 9:54 AM, Frank Warmerdam <warmer...@pobox.com> wrote: > Nik, > > I assume you are using the "built in" libtiff in GDAL. In that case the file > gdal/frmts/gtiff/libtiff/tif_config.h will include cpl_port.h and includes > this line: > > #define TIFF_UINT64_T GUIntBig > > I assume TIFF_UINT64 ultimately is used to define uint64. > > So I think you need to go through gdal/port/cpl_port.h and > gdal/port/cpl_config.h to try and figure out how GUIntBig is getting defined. > In cpl_port.h it helps to search for the block of code titled "64bit > support". I would guess you want to use "unsigned long long" in which case > you would need to have HAVE_LONG_LONG defined in cpl_config.h. > > I'm not aware of any recent changes in this logic so I'm not sure why it used > to work and doesn't now. > > Best regards, > Frank > > > > > > > On Thu, Sep 26, 2013 at 4:33 PM, Nik Sands <nix...@nixanz.com> wrote: > Hi list members, > > I've been using GDAL 1.10 as a statically linked library in an iOS app for > some time. I recently recompiled GDAL again from the same local set of > source files, using my notes on configuration options that I used last time, > and ever since I've been having a problem every time the app attempts to open > an image file. > > The app fails an assert() in the included tiff library (in tif_open.c), > throwing the error: > > Assertion failed: (sizeof(uint64)==8), function TIFFClientOpen, file > tif_open.c, line 99. > > The line in question is the last line of the code snippet from tif_open.c > below: > > /* The following are configuration checks. They should be redundant, > but should not > * compile to any actual code in an optimised release build anyway. > If any of them > * fail, (makefile-based or other) configuration is not correct */ > assert(sizeof(uint8)==1); > assert(sizeof(int8)==1); > assert(sizeof(uint16)==2); > assert(sizeof(int16)==2); > assert(sizeof(uint32)==4); > assert(sizeof(int32)==4); > assert(sizeof(uint64)==8); // <- SIBABRT HERE > > The comments indicate that there may be a problem with the "configure" > options I used when building GDAL, however I'm using exactly the same options > (copy and pasted) as I used last time when it worked OK. > > So this leads me to think that perhaps something has changed in my > environment, and the only thing I can think of is that I may be using a > different version of GCC (I'm using the 'gcc' included with Apple's 'Xcode' > IDE, and since the last compile of GDAL, I've upgraded from a beta build of > Xcode to the production build of Xcode 5). > > I've tried it with GDAL 1.10.1 as well and get exactly the same problem. > > I'm stumped as to how to proceed with resolving this issue. Can anybody help > me to overcome this? > > Note that the problem occurs when running on the real iOS device (armv7s) and > on the iOS simulator (i386). > > Cheers, > Nik. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > -- > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | Geospatial Software Developer
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev