This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>To: address@hidden >From: "Susan C. Cherniss" <address@hidden> >Subject: Problem building netCDF 2.4.3 for UNICOS 8 >Organization: NASA Ames Research Center >Keywords: 199612112358.AA03260 Hi Susan, > I am trying to build netCDF 2.4.3 for UNICOS 8.0.4 on a C90 and have > run into problems compiling netcdf.cc. The details are below. > Any suggestions on getting past this problem? Yes, if you can get by without the C++ interface to netCDF then you can just define CXX="" before running the configure script (do a make clean first and rm config.cache). You can set the value of CXX as an environment variable or in the CUSTOMIZE file. > 0. CC -V > Cray C++ Version 2.0.0.2 12/11/96 15:37:04 > > 1. Output from the command `uname -a'. > vn vn 8.0.4.2 nas.55 CRAY C90 ... > making `all' in directory /u/vb/cherniss/netcdf/unicos8.0.4/cxx > > gmake[1]: Entering directory `/u/vb/cherniss/netcdf/unicos8.0.4/cxx' > CC -c -I../libsrc netcdf.cc > CC-403 CC: ERROR File = netcdf.hh, Line = 76 > Member function function "NcFile::add_att" has already been declared. > > NcBool add_att( NcToken attname, ncbyte ); > ^ I've appended a description of the details of the problem, if you decide you need the C++ interface and want to try to get Cray to fix the compiler problem. I've reported it already ... _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu I've looked into the C++ errors revealed by trying to compile the netCDF 2.4 C++ interface on the Cfront-based Cray compiler on [a local Cray] and concluded that this is a compiler problem that we can't easily work around. I've isolated the problem to a small demonstration program that demonstrates a failure to distinguish plain char, signed char, and unsigned char as three distinct types for overloading function signatures: -------------------------------------- #include <iostream.h> class X { public: X() {} void f(char c) {cout << "char " << c << "\n";} void f(signed char s) {cout << "signed char " << s << "\n";} void f(unsigned char u) {cout << "unsigned char " << u << "\n";} }; int main() { X x; char c = 'c'; signed char s = -13; unsigned char u = 'u'; x.f(c); x.f(s); x.f(u); return 0; } -------------------------------------- The above program conforms to the proposed C++ standard, as far as I have been able to determine (see, for example, chapters 3 and 4 of the draft standard at <URL http://www.csci.csusb.edu/dick/c%2b%2bstd/september/>). It compiles with no errors or warnings and runs fine on the following platform/compiler combinations: SunOS 5.4 or SunOS 4.1.4, CC 3.0.1: SunOS 5.4, g++ 2.6.3: IRIX 6.1, CC OSF1 3.2, g++ 2.7.2: AIX 4.1.4, xlC: It also runs fine on the following platform, though it produces a warning: IRIX 5.3, CC "chars.cc", line 7: warning(3672): Mangling of signed character does not match cfront name mangling. void f(signed char s) {cout << "signed char " << s << "\n";} ^ However, it fails to compile on [a local Cray]. --Russ