20010725: problems linking C++ netCDF on SunOS 5.7

Martha,

Our resident netCDF C++ expert, Russ Rew, will return next week. So take
what I say with some salt.

> To: address@hidden
> cc: address@hidden
> From: Martha Limber <address@hidden>
> Subject: problems linking netCDF on SunOS 5.7
> Organization: ncar/rap
> Keywords: 200107251747.f6PHlN121670

The above message contained the following:

> We are having trouble linking C++ code which uses the netcdf libraries
> (v. 3.5) on SunOS 5.7. The code links fine with netcdf 3.4.
> 
> Attached is a simple example.  The error message I get is:
> 
>  Undefined                       first referenced
>  symbol                             in file
> NcFile::NcFile(char const *, NcFile::FileMode)main.o

I'm not surprised at the above.  I couldn't find a 2-argument NcFile
constructor.  The only constructor I found was

    NcFile::NcFile( const char* path, FileMode fmode,
                    size_t* chunksizeptr, size_t initialsize  )

This 4-argument form has apparently existed since October 1998.

> NcFile::~NcFile(void)               main.o

Now this does surprise me.  The C++ interface does have a 0-argument
destructor:

    NcFile::~NcFile( void )

Could it be that a different C++ compiler built the netCDF library than
the one you're using to compile your program and that the C++
name-mangling is different in the two compilers?

Just to cover all bases, does your link-line have an explicit reference
to the (separate) C++ netcdf library (e.g. "-lnetcdf_c++")?

> ld: fatal: Symbol referencing errors. No output written to test
> collect2: ld returned 1 exit status
> 
> Do you have any idea what the problem could be?
> 
> Thanks,
> 
> Martha 
> 
> 
> *********************************************************
> Martha N. Limber, Ph.D.
>  
> National Center for Atmospheric Research
> Research Applications Program
> P.O. Box 3000
> Boulder, CO 80307-3000
>  
>   email: address@hidden
>   phone: (303) 497-8436
>   fax:   (303) 497-8401
>  
> *********************************************************

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