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

[netCDF #GOK-784955]: Problem encountered: catastrophic error: cannot open source file "stdarg.h"

> Here's a short update from my side:
> >
> >  If you don't really
> >> need the C++ API for netCDF, you might try rebuilding with the environment
> >> variable CXX='' or the configure option --disable-cxx and see if stdarg.h
> >> is
> >> still a problem.
> >
> >
> > Sorry, I am really new to handling servers. I am not really how to rebuild
> > the environment by setting CXX=''. Does adding a line that says $alias
> > CXX='' in my ~/.bashrc accomplish the work?
> >
> I have tried several ways of changing my environment settings (CXX='' or
> CXX="" or CXX=c++ or CXX='c++') but these still don't solve the issue.

CXX is the name of an environment variable that can be set before running
the configure script.  How you should set it depends on what Unix "shell"
you are running.  the shell is the command interpreter, and unfortunately 
Unix systems have several different shells with incompatible syntaxes for
setting environment variables.

If you are using ksh, bash, or sh, you can set an environment variable on
the same line as a command but before the command, which sets that environment
variable temporarily, while the command is run.  So with one of those shells,
for example, you could try

   CXX=c++ ./configure

with whatever arguments you are giving configure on the same line.

If you are using the csh shell, you need to use something like

   setenv CXX c++

> I have also tried searching for stdarg.h filenames.
> Here are the directories stated:
> /usr/include/c++/4.2.1/tr1/stdarg.h
> /usr/lib/clang/3.1/include/stdarg.h
> /usr/llvm-gcc-4.2/include/gcc/darwin/4.2/stdarg.h
> /usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/include/stdarg.h
> /usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/install-tools/include/stdarg.h
> It seems then that the installation could probably work if c++ would be
> forced to be the compiler instead of g++. I am not really sure how to do
> this though. Could you please advise me if this could be done? I am not
> sure how to resolve the icc and g++ incompatibility issue.

If you issue the command

  which c++

do you get back a path to the C++ compiler?  If so, then just setting the CXX 
environment variable to "c++" before invoking the configure script may work.  If
not, then you need to set your PATH environment variable to include the
directory containing the c++ compiler, if that's the problem.  Or maybe you
should try iCC or ic++, if either of those is the name of a c++ compiler that
is copmpatible with icc.

> For now, I am still using the installation parameters of GMT from SOEST,
> Hawaii (edited to install netCDF to version 4.0.1 and to use icc as
> compiler) to install netCDF since it seems to be easier and because I need
> both GMT and netCDF to install and run the model I'll be using. Would you
> recommend other ways of installing netCDF? I have checked the UniData
> website and it seems that several bugs have been reported for installation
> in OS X in newer versions, which is why I have tried installing 4.0.1.

I don't think GMT uses netCDF-4 features.  If so, you could include the 
configure option --disable-netcdf-4 to make the build simpler.  If GMT
doesn't use the OPeNDAP remote access feature in netCDF, you could also include
the --disable-dap option to configure to make the build even simpler.  If
GMT doesn't need the C++ interface, you could also include the argument
--disable-cxx so that configure wouldn't generate makefiles to build a C++ 

Version 4.1.3 is better than version 4.0.1 in many respects, and it should also
be somewhat more portable.  With netcdf-4, dap, and cxx disabled, it should be
just as simple to build as version 4.0.1.


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

Ticket Details
Ticket ID: GOK-784955
Department: Support netCDF
Priority: Normal
Status: Closed

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.