[Gdal-dev] building gdal for OpenZaurus

[Mateusz Loskot]

Frank Warmerdam wrote:
> Yan Seiner wrote:
>> I am trying to cross-compile gdal for OpenZaurus.  I am using the 
>> development toolchain (3.5.4.2-rc2).  The build fails with:
>> 
>> |  arm-linux-g++ -march=armv5te -mtune=xscale -Wall 
>> -I/home/local/zaurus/tmp/staging/arm-linux/include 
>> -fexpensive-optimizations -fomit-frame-pointer -frename-registers 
>> -O2 -fpermissive -DOGR_ENABLED 
>> -I/home/local/zaurus/tmp/staging/arm-linux/include 
>> -I/home/local/zaurus/tmp/work/armv5te-linux/gdal-1.3.2-r1/gdal-1.3.2/port
>>  -c cpl_strtod.cpp  -fPIC -DPIC -o .libs/cpl_strtod.o | 
>> cpl_strtod.cpp:239: error: declaration of `double nan(const char*)'
>>  throws different exceptions | 
>> /home/local/zaurus/tmp/staging/arm-linux/include/bits/mathcalls.h:225:
>>  error: than previous declaration `double nan(const char*) throw 
>> ()' | cpl_strtod.cpp:249: error: declaration of `float nanf(const 
>> char*)' throws different exceptions | 
>> /home/local/zaurus/tmp/staging/arm-linux/include/bits/mathcalls.h:225:
>>  error: than previous declaration `float nanf(const char*) throw 
>> ()'
>> 
>> Can anyone shed some light on this?  I am pretty much out of my 
>> depth on these types of errors....
> 
> Yan,
> 
> The problem appears to be that cpl_strtod.cpp is providing a 
> declaration for nan() that conflicts with the system one.  The code 
> tries to avoid this by only declaring it if the HAVE_DECL_NAN is 
> unset or zero in cpl_config.h (as set by configure), but it seems 
> that configure on your platform has not correctly set this item.

Frank,

My suggestion about replacing <math.h> to <cmath> fix this ambiguity,
because the latter puts everything to std:: namespace.
Though, nan is not a standard math function for C++.

Another option is there are still some bugs in gcc/libstdc++,
especially in older versions. I remember there were problems like mixing
C and C++ declaration in global space instead of std.

Yan, I'd suggest you to ask on gcc/libstdc++ mailing list too.

Here is one of my report about similar problem:
http://gcc.gnu.org/ml/libstdc++/2006-02/msg00086.html

and Joe Buck explains:

-----
It appears that the problem is in the headers; despite the ISO
requirement, doing

#include <cstring>

on a GNU/Linux RHEL 3 system provides the C-style declaration, for
versions 3.2.3, 4.0, and 4.1-pre.
-----

So, there still may be some similar issues.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net