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

Re: 20040614: netcdf build report on NetBSD/sparc

>To: address@hidden
>cc: address@hidden
>From: der Mouse <address@hidden>
>Subject: netcdf build report
>Organization: ?
>Keywords: 200406142044.i5EKiPtK000010 netCDF-3.5.1 NetBSD

Hi,

> I got netCDF 3.5.1 and tried to set it up on NetBSD/sparc 1.4T; I also
> tried it on NetBSD/i386 1.6.1 (the former was a preparatory step; the
> latter is close to the actual target system).
> 
> First, thank you very much.  It looks like a very useful library for
> our application (which is still fairly nascent, or I'd go into more
> detail).
> 
> The build ran into problems with the C++ and FORTRAN versions.  For my
> purposes these are not particularly important, but on the chance that
> the actual problems behind these errors are something you care about, I
> thought I'd drop you a line.  (I also can report success for the C
> interface.)

Thanks for the detailed report on your NetBSD installation.  We've
seen the problems you report on other platforms, but it's still good
to know that the C interface built correctly for NetBSD 1.6.1.

> I ended up doing three builds.  The first failed trying to build the
> C++ stuff; the second, I disabled the C++ stuff and it failed in the
> FORTRAN code.  The third, I disabled C++ and FORTRAN and it worked
> (though with a warning that I think also likely indicates a problem,
> albeit a relatively minor problem).
> 
> First, a brief summary of the problems, in the hope that my experience
> with build issues allows me to include just the useful stuff.  (I'll
> include the full data requested by the reporting-problems section of
> the install document later.)

> First thing:
> 
> | Making `all' in directory /local/src/netcdf/netcdf-3.5.1--1/src/ncgen
> [...]
> | Warning: ncgentab.c is out-of-date with respect to ncgen.y
> | Warning: It should be recreated via yacc on an OSF/1 system
> | c89 -c -O -I../libsrc -I.  -DNDEBUG ncgentab.c
> [...]
> 
> I'm not sure what's going on here.  I had a quick look at ncgen.y and
> didn't see anything obviously nonportable, but I didn't try running
> yacc on it to see if it "worked".  (I can if you like.)

The ncgen.y is meant to be portable, and this was apparently an
artifact of ncgentab.c having the same time stamp as ncgen.y in
version 3.5.1.  We've fixed it in the next version.


> Second thing:
> 
> | Making `all' in directory /local/src/netcdf/netcdf-3.5.1--1/src/cxx
> | 
> | c++ -c  -I../libsrc -I.  -DNDEBUG netcdf.cpp
> | In file included from netcdfcpp.h:16,
> |                  from netcdf.cpp:12:
> | ncvalues.h:14: sstream: No such file or directory
> | *** Error code 1
> | 
> | Stop.
> [...]
> 
> I'm not sure what's up here either.  My C++-fu is approximately
> nonexistent; I assume this is spec skew between the C++ compiler I have
> and the spec you wrote to (this reinforced by my experience, below, on
> the 1.6.1 machine).  In any case, though, my next step was to try a run
> with CXX set to "", since I don't particularly care about the C++
> interface.

You're right, this is an indication that your C++ compiler is not up
to date with the C++ standard.  <sstream> now replaces the deprecated
header <strstream.h>

> | m4 -B10000 attr.m4 >attr.c
> | m4: illegal option -- B
> | m4: illegal option -- 1
> | m4: illegal option -- 0
> | m4: illegal option -- 0
> | m4: illegal option -- 0
> | m4: illegal option -- 0
> | m4: illegal option -- B
> | usage: m4 [-Dname[=val]] [-Uname]
> | *** Error code 1
> | 
> | Stop.
> 
> Investigating why I didn't get similar errors from the first run, it
> appears to be because the copying method I used to create the --2
> directory did not preserve modify times, and happened to make attr.m4
> newer than attr.c.  It strikes me as a very bad idea for the
> distribution's build success to depend on files' mtimes being preserved
> from the distribution; indeed, the yacc warning looks as though it's
> happening for similar reasons, and it's less catastrophic only because
> the Makefile is prepared for that timestamp error on non-OSF/1 systems.
> 
> I copied modify times and it seems to have been a successful
> workaround.

Yes, it's necessary to preserve the file creation times in the
distribution to avoid problems like the above.  To install netCDF, you
should not even have to have access to m4, that's just for developers.
When untarring or unzipping distributions, file modification times are
preserved for that reason.  It's "standard practice" with source
distributions to rely on preservation of file modification times from
unpacking.

> This build then fell over in the FORTRAN code:
> 
> | Making `all' in directory /local/src/netcdf/netcdf-3.5.1--2/src/fortran
> | 
> | c89 -c -O -I../libsrc  -DNDEBUG fort-attio.c
> | In file included from ncfortran.h:13,
> |                  from fort-attio.c:6:
> | cfortran.h:48: warning: deprecated symbol "unix" is no longer predefined
> | In file included from ncfortran.h:13,
> |                  from fort-attio.c:6:
> | cfortran.h:155: #error "cfortran.h:  Can't find your environment among:\
> |     - MIPS cc and f77 2.0. (e.g. Silicon Graphics, DECstations, ...)     \
> |     - IBM AIX XL C and FORTRAN Compiler/6000 Version 01.01.0000.0000     \
> |     - VAX   VMS CC 3.1 and FORTRAN 5.4.                                  \
> |     - Alpha VMS DEC C 1.3 and DEC FORTRAN 6.0.                           \
> |     - Alpha OSF DEC C and DEC Fortran for OSF/1 AXP Version 1.2          \
> |     - Apollo DomainOS 10.2 (sys5.3) with f77 10.7 and cc 6.7.            \
> |     - CRAY                                                               \
> |     - NEC SX-4 SUPER-UX                                                  \
> |     - CONVEX                                                             \
> |     - Sun                                                                \
> |     - PowerStation Fortran with Visual C++                               \
> |     - HP9000s300/s700/s800 Latest test with: HP-UX A.08.07 A 9000/730    \
> |     - LynxOS: cc or gcc with f2c.                                        \
> |     - VAXUltrix: vcc,cc or gcc with f2c. gcc or cc with f77.             \
> |     -            f77 with vcc works; but missing link magic for f77 I/O. \
> |     -            NO fort. None of gcc, cc or vcc generate required names.\
> |     - f2c    : Use #define    f2cFortran, or cc -Df2cFortran             \
> |     - NAG f90: Use #define NAGf90Fortran, or cc -DNAGf90Fortran          \
> |     - Absoft UNIX F77: Use #define AbsoftUNIXFortran or cc 
> -DAbsoftUNIXFortran \
> |     - Absoft Pro Fortran: Use #define AbsoftProFortran \
> |     - Portland Group Fortran: Use #define pgiFortran"
> | *** Error code 1
> | 
> | Stop.
> [...]
> 
> Since I don't particularly care about the FORTRAN environment either, I
> did a third run, with CXX="" FC="" (with care taken over mtimes).  This
> run appears to have worked - the build finishes and "make test" is
> happy.

If your fort77 compiler was just a wrapper for f2c, you would have
needed CPPFLAGS=-Df2cFortran to get it to work.

Thanks again for the problem report.

--Russ
_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden          http://www.unidata.ucar.edu/staff/russ