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

Re: 20010820: Problem linking to libnetcdf_c++ on prospect/tru64

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.

  • Subject: Re: 20010820: Problem linking to libnetcdf_c++ on prospect/tru64
  • Date: Mon, 20 Aug 2001 17:08:41 -0600
>To: netCDF Support <address@hidden>
>cc: address@hidden,
>cc: Mary Haley <address@hidden>
>From: Charlie Zender <address@hidden>
>Subject: ostream problem in netcdf-C++ interface?
>Organization: UCAR/Unidata
>Keywords: 200108082356.f78Nu5115574

Charlie,

I just built and tested netcdf-3.5.1-beta on prospect.ucar.edu, and it
built and passed all tests out of the box, with no default environment
variable settings.  In particular, no value for CXXFLAGS was
necessary, although you had written

> ... The compaq alpha cxx compiler has some flags to use old, non-ISO
> streams, but those break my code in other ways.

So if your code compiles with no special C++ compiler flags, the
3.5.1-beta should work fine for you.

I also verified that netcdf-3.5.1-beta won't build with the C++
compiler flag "-std strict_ansi".

However, if your code *requires* this extra C++ flag to compile, you
may have to make local modifications to the netCDF include file to
make it work with your code, because it may not be possible to make a
version that complies with the C++ strict ANSI rules and also compiles
with older C++ compilers.  That's more or less what the C++
Portability Guide I referenced in an earlier message said.

If we can get the netCDF library to compile and pass all of its tests
with one or two common compilers and a specified set of compiler flags
on each platform, we consider the library ported to that platform.  If
we also have to make sure it works under all combinations of compiler
flags on each platform, the job of porting is exponentially more
difficult.  When all C++ compilers accept and correctly compile strict
ANSI C++ code, we can test under strict requirements, but until then
we have to distribute something that works on the wide variety of C++
compilers that are out there.

Nevertheless, I'll see what I can do to get around this problem, but a
solution that involves changing the code to make it work with the
particular compiler flags you are using may not be possible ...

--Russ