[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 19981128: netCDF-3.4 on FreeBSD using gcc 2.8.1

Dear Masatake E. HORI,

> From: "Masatake E. HORI" <address@hidden>
> Subject: netCDF-3.4 on FreeBSD
> Organization: University of Tsukuba, Institute of Geo-Science
> Keywords: 199811280250.TAA17893 netCDF 3.4 FreeBSD

In the above message, you wrote:

> I was trying to compile netCDF-3.4 on my FreeBSD using gcc-2.8.1,
> and I'm having 2 problems.

We have a BSD/OS system here -- but it has gcc version 2.7.2.1 (the g77
compiler apparently doesn't yet work with gcc 2.8).  We're installing
gcc 2.8, however, in order to help diagnose the problem.

> I've made my compilation with gmake, with the enviroment variables like,
> CC = gcc
> CCFLAG = -Df2cFortran
> CXX = g++

I trust that when you defined the above variables that you didn't embed
spaces around the equals sign.

Would you please send me the standard output and standardd error from
executing the configure script.

> It compiles successfully, other than some warnings like, 
> 
> /usr/include/g++/streambuf.h:394: warning: invalid type `void *' for default 
> argument to `ios *'
> In file included from ncvalues.cc:10:
> /usr/include/g++/iostream.h:50: warning: invalid type `void *' for default 
> argument to `ostream *'
> /usr/include/g++/iostream.h:117: warning: invalid type `void *' for default 
> argument to `ostream *'
> /usr/include/g++/iostream.h:221: warning: invalid type `void *' for default 
> argument to `ostream *'

The above warnings indicate a problem with the g++ header files and
shouldn't affect the netCDF package.

> However, when I do "gmake test", after some successful tests, I get
> 
> *** Testing nc_get_vara_uchar ... 
>       FAILURE at line 1665 of test_get.c: value read not that expected
>       FAILURE at line 1665 of test_get.c: value read not that expected
>  262 good comparisons. 
>       ### 2 FAILURES TESTING nc_get_vara_uchar! ###
> *** Testing nc_get_vara_schar ... 
>       FAILURE at line 1830 of test_get.c: value read not that expected
>       FAILURE at line 1830 of test_get.c: value read not that expected
>  267 good comparisons. 
>       ### 2 FAILURES TESTING nc_get_vara_schar! ###
> *** Testing nc_get_vara_short ... 
>       FAILURE at line 1995 of test_get.c: value read not that expected
>  681 good comparisons. 
>       ### 1 FAILURES TESTING nc_get_vara_short! ###
> *** Testing nc_get_vara_int ... 
>       FAILURE at line 2160 of test_get.c: value read not that expected
>       FAILURE at line 2160 of test_get.c: value read not that expected
>       FAILURE at line 2160 of test_get.c: value read not that expected
>       FAILURE at line 2160 of test_get.c: value read not that expected
>  1185 good comparisons. 
>       ### 4 FAILURES TESTING nc_get_vara_int! ###
> *** Testing nc_get_vara_long ... 
>       FAILURE at line 2325 of test_get.c: value read not that expected
>  1188 good comparisons. 
>       ### 1 FAILURES TESTING nc_get_vara_long! ###
>      .
>      .
>    so on with many simular failures...
>      .
>      .
> Total number of failures: 89
> 
> Any guess on what I may possibly doing wrong ?

As a guess, based on support-email on this topic, I'd say that the C
header-file that defines the extreme values for "signed character",
"unsigned character", "short", and "int" types is broken.  This
header-file is <limits.h>.

> Or, is it okey to ignore these messages if I'm only using the C and
> FORTRAN libraries and not the C++?

Possibly.  Normally, the above failure messages during the "make test"
would indicate a serious problem with the netCDF library that you built.
However, if the <limits.h> header file is broken, then the netCDF
library would be OK regardless of the above messages.  I suspect that
this is the case.

One way to test the netCDF library would be to run the "ncdump" utility
on a previously-existing file of yours that contained "byte" values
(e.g. like an image).  See if the values it display are correct.

Another way to test the netCDF library would be to execute an
application of yours that is linked against the new library and that
reads-in a previously existing netCDF file that containes "byte"
values.

> Also, I've found some simular behaviour being reported in your archive
> of support e-mails ( 2747 and 2733, the first two hits that I get when
> I search by "FreeBSD"). That was in the end of last year. So I wonder,
> is there any progress made since then on this case?

Resolution of that problem depends on correction of the broken <limits.h>
header-file -- something that is outside our scope.

> Another problem.
> When I "gmake install" the build (ignoring the failure of"gmaketest")
> I get an error like, 
> 
> catman -w -M /data/ulysses2/packages/netcdf-3.4/man
> Don't start this program as root, use:
> echo /usr/bin/catman -w -M /data/ulysses2/packages/netcdf-3.4/man | nice -5 
> su -m man
> usage: catman [-h|-help] [-f|-force] [-p|-print] [-r|remove]
>               [-v|-verbose] [directories ...]
> gmake: *** [/data/ulysses2/packages/netcdf-3.4/man/whatis] Error 1
> 
> 
> Is this because my catman command is different from other platforms?
> Is there a workaround? or, can I safely ignore it?

Unfortunately, users can't create a package-specific "whatis" database
under FreeBSD.  So you my safely ignore the above message because it's
the last thing a "make install" attempts to do and its failure doesn't
affect installation of the netCDF package.

--------
Steve Emmerson   <http://www.unidata.ucar.edu>