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

Re: netCDF Mismatch in Naming Conventions

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: netCDF Mismatch in Naming Conventions
  • Date: Mon, 05 Apr 2004 13:06:15 -0600
>To: address@hidden
>From: "James K Lewis" <address@hidden>
>Subject: Re: 20040405: netCDF Mismatch in Naming Conventions
>Organization: Scientific Solutions, Inc.
>Keywords: 200404051802.i35I2VCT014680 Lahey f90 w2k

Hi Jim,

> All:  A number of hours by several people have been spent in trying to get
> netCDF F90 to compile and link on a Win32 machine (W2K) using Lahey Fortran.
> It now appears that the primary problem is a mismatch in the naming
> conventions between the Lahey compiler and the Microsoft Visual C++ we have
> been using to generate the netcdf.lib for the f77 netCDF functions.

I think you will need to either use the same compiler that you
compiled the library with to compile and link F90 programs with it.
As you have discovered, there is no standard for naming conventions
for calling C from Fortran, and different compilers do it in different
ways, even on the same platform.  So I would recommend rebuilding the
netCDF library with the Lahey compilers and linking to that, since I
don't know anyone who has had success yet in building the F90 part of
the library with the Microsoft Visual C++ package.

> Right now, I get 39 unresolved external references when trying to link.  A
> simple example of the mismatches is fn_inq_libvers.  When generating the
> netcdf.obj using f90netcdf.f90 (and associated include *.f90's), the Lahey
> compiler names the reference to fn_inq_libvers in netcdf_externals.f90
> 'fn_inq_libvers@0'.  In netcdf_externals.f90, fn_inq_libvers is defined as
> 'character (len = 80)'.
> 
> In the fortran directory from which we use MS VC++ to generate the f77 lib,
> fn_inq_libvers in netcdf.inc is defined as 'character*80'.  The
> fn_inq_libvers is referenced in fort-misc.c, ncfortran.h, netcdf.inc, and
> netcdf.3f.  When MS VC++ generates the netcdf.lib file, the naming
> convention gives 'fn_inq_libvers@8'.  Thus, the linker can't find
> 'fn_inq_libvers@0'.
> 
> Out of the 79 fn functions, there are 39 of these mismatches.  Does anyone
> know of a way for forcing either the Lahey conventions to match the MS VC++
> conventions or visa versa?

According to:

  http://www.unidata.ucar.edu/packages/netcdf/other-builds.html#lahey-f95-v6

  Gareth Williams reports that compiling with a CPPFLAGS environment
  variable that includes "-DNAGf90Fortran" works with the Lahey
  fortran compiler lf95 (version L6.00a) and
  netcdf-3.5.1-beta10. Presumably this will also work with later
  versions as well.

There's also more information here on Dirk Slawinski's port to use of
the Lahey F95 compiler on Windows NT:

  http://www.unidata.ucar.edu/packages/netcdf/other-builds.html#lahey-nt

We will be able to test this on the released 3.5.1 version soon, but I
thought I'd pass this along first, in case it helps.

--Russ

_____________________________________________________________________

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