Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#4705 closed defect (fixed)

NetCDF compilation failure on solaris 10 with gcc

Reported by: bwalton Owned by: etourigny
Priority: normal Milestone:
Component: default Version: 1.9.1
Severity: normal Keywords:
Cc:

Description

On Solaris 10 the netCDFRasterBand::CheckValidData function was triggering errors of the form:

non-floating-point argument in call to function 'builtin_isnan'

This is because math.h includes iso/math_c99.h where isnan is defined as builtin_isnan when GCC v4 or greater is used. This method requires a floating point data type.

Fix this issue by casting all values checked by CPLIsNan in this function to double.

(See attached patch.)

Attachments (1)

0001-Force-use-of-double-data-type-before-checking-for-is.patch (1.4 KB ) - added by bwalton 12 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 by Even Rouault, 12 years ago

Owner: changed from warmerdam to etourigny

comment:2 by etourigny, 12 years ago

bwalton - are there any other places where this fix is needed? I see only one line changed in the patch.

I don't have access to Solaris so I'll have to trust you one this one - but I'll test the fix in linux. Can you run the autotest in autotest/gdrivers/netcdf.py after this fix to make sure it doesn't just compile but runs ok? Please do a svn update of trunk first - this needs new test 30.

Which compiler does this happen with? This works fine with gcc 4 in linux.

comment:3 by etourigny, 12 years ago

Your proposed fix seems to work on in linux, gcc 4.6.1 . Compiles and test 30 passes.

I'll wait for your input to commit this to trunk and 1.9, thanks.

comment:4 by bwalton, 12 years ago

It's gcc 4.7 on Solaris 10 that I'm using. I'll try the test suite tonight as I won't have time today. I understand that I'll need a patch from trunk before I can give it the proper workout though? (I'm building from the 1.9.1 tarball.)

I'm having other build issues in another module though...will I be able to run enough of the test suite to ensure that the netcdf stuff is functional without having a full build completed?

Thanks -Ben

in reply to:  4 comment:5 by etourigny, 12 years ago

Replying to bwalton:

It may be related gcc-4.7 and not Solaris then...

It's gcc 4.7 on Solaris 10 that I'm using. I'll try the test suite tonight as I won't have time today. I understand that I'll need a patch from trunk before I can give it the proper workout though? (I'm building from the 1.9.1 tarball.)

Instead of running the autotest, you can just use gdalinfo to test for the right checksum

$ wget http://trac.osgeo.org/gdal/export/24580/trunk/autotest/gdrivers/data/trmm-nan.nc

$gdalinfo -checksum trmm-nan.nc
[...]
Band 1 Block=40x1 Type=Float32, ColorInterp=Undefined
  Checksum=62519
[...]

Trunk is mostly the same as 1.9.1, so you don't need to get trunk (although that helps if you want to submit more patches).

I'm having other build issues in another module though...will I be able to run enough of the test suite to ensure that the netcdf stuff is functional without having a full build completed?

Are these also related to gcc-4.7 ?

You need a fully functional gdal build before you run the autotest - although if the other modules are optional (e.g. optional drivers) you can disable them temporarily.

Running the autotests once everything compiles is a good way to make sure the build is ok - although it can take some time, especially the ogr tests.

Thanks -Ben

comment:6 by bwalton, 12 years ago

I have gcc 4.6 available too, so I can eliminate (or identify) the gcc version level as the culprit. I believe it's due to the solaris headers (for C99 compliance) themselves though. I'll do the legwork on this tonight.

This build is for OpenCSW and we have a build farm that we make available to upstream developers. We have solaris 8-11 systems for both i386 and sparc. We could get you an account if that would help? (Our minimum targets are solaris 10 for binary packages now, but we try to hit 9 in some cases still. The 8 boxes are legacy only but still available.)

Thanks -Ben

comment:7 by etourigny, 12 years ago

Ben,

Please see if it's a gcc-4.7 or a Solaris issue if you have the time.

If you can get things resolved on your end it's probably better, although if you need to and it's not too much of a hassle to get things setup I could help out - but I don't have time to learn Solaris intricacies though, sorry...

Although perhaps Even would be interested, especially if there are a number of issues that need to be resolved. I'm mostly involved in the netcdf driver.

comment:8 by bwalton, 12 years ago

It seems to work. I used the gdalinfo option as I don't even see autotest (must be part of the svn trunk?)...It looks good to me, but I only package this software, I don't use it. Here's my output:

bwalton @ unstable10x : ~/opencsw/gdal/trunk/work/solaris10-i386/build-isa-penti um_pro/gdal-1.9.1 $ ./apps/gdalinfo -checksum trmm-nan.nc Driver: netCDF/Network Common Data Format Files: trmm-nan.nc Size is 40, 40 Coordinate System is `' Origin = (-80.000000000000000,-10.000000000000000) Pixel Size = (0.250000000000000,-0.250000000000000) Metadata:

latitude#axis=Y latitude#long_name=Latitude latitude#standard_name=latitude latitude#units=degrees_north longitude#axis=X longitude#long_name=Longitude longitude#standard_name=longitude longitude#units=degrees_east NC_GLOBAL#calendar=standard NC_GLOBAL#CDI=Climate Data Interface version 1.5.4 (http://code.zmaw.de/projects/cdi) NC_GLOBAL#CDO=Climate Data Operators version 1.5.4 (http://code.zmaw.de/projects/cdo) NC_GLOBAL#center=gsfc NC_GLOBAL#comments=file created by grads using lats4d available from http://dao.gsfc.nasa.gov/software/grads/lats4d/ NC_GLOBAL#Conventions=CF-1.4 NC_GLOBAL#history=Fri Jun 15 11:23:24 2012: cdo setrtoc,-1,0,nan trmm.nc trmm-nan.nc

Wed Sep 07 22:33:59 2011: cdo sellonlatbox,-80,-70,-20,-10 tmp4-noc.nc tmp5.nc Wed Sep 7 22:33:53 2011: ncatted -a Conventions,global,d tmp4.nc tmp4-noc.nc Wed Aug 24 12:59:04 2011: ncatted -D 10 -a CoreMetadata.0,global,d -a ArchiveMetadata.0,global,d tmp3.nc tmp4.nc Tue Aug 23 21:04:45 2011: cdo seltimestep,1 tmp2.nc tmp3.nc Tue Aug 23 19:19:18 2011: cdo selvar,pcp tmp1.nc tmp2.nc Tue May 17 19:34:24 2011: cdo sellonlatbox,-85.25,-29.625,15.25,-50 3B43.2011.nc tmp1.nc Tue May 17 19:26:31 2011: cdo mergetime 3B43.110101.6A.nc 3B43.110201.6A.nc 3B43.110301.6A.nc 3B43.110401.6A.nc 3B43.2011.nc

NC_GLOBAL#model=geos/das pcp#_FillValue=-9999.9004 pcp#comments=Unknown1 variable comment

pcp#grid_name=grid-1 pcp#level_description=Earth surface pcp#long_name=precipitation:Precipitation pcp#time_statistic=instantaneous time#calendar=standard time#standard_name=time time#units=hours since 2011-01-01 00:00:00

Corner Coordinates: Upper Left ( -80.0000000, -10.0000000) Lower Left ( -80.0000000, -20.0000000) Upper Right ( -70.0000000, -10.0000000) Lower Right ( -70.0000000, -20.0000000) Center ( -75.0000000, -15.0000000) Band 1 Block=40x1 Type=Float32, ColorInterp=Undefined

Checksum=62519 NoData Value=-9999.900390625 Metadata:

_FillValue=-9999.9004 comments=Unknown1 variable comment grid_name=grid-1 level_description=Earth surface long_name=precipitation:Precipitation NETCDF_DIMENSION_time=0 NETCDF_time_units=hours since 2011-01-01 00:00:00 NETCDF_VARNAME=pcp time_statistic=instantaneous

comment:9 by bwalton, 12 years ago

I've now tested on sparc as well and I get the same results from gdalinfo there too. If it would help, I can do the builds with solaris studio CC as well?

comment:10 by etourigny, 12 years ago

Resolution: fixed
Status: newclosed

Fixed in 1.9 (r24594) and trunk (r24595).

If you can check the solaris studio CC build as well, that would be great, thanks.

comment:11 by bwalton, 12 years ago

Ok, my testing has revealed some compilation issues that I'm creating patches for (I'll submit them when I get a full build). After a full build is ready, I'll test the same gdalinfo calls.

Note: See TracTickets for help on using tickets.