[netCDF #YYO-369400]: netcdf-fortran-4.4.0 installation error

Hi Sang-Mi Lee and Richard,

> I wonder if this is a result of where netcdf_overloads.f90 gets included
> into netcdf.f90. Sometimes, the order in which things are processed by
> the compiler (particularly when using include files) can generate this kind of
> error. Also, I noticed in a previous post on this that
> the person compiling was using parallel make (make -j8). I never compile
> with parallel make so I'm not sure if this is something that might
> make the Intel compiler gag.

I think the problem may be caused by trying to build netcdf-fortran using an
installed netCDF-C library that doesn't support netCDF-4.  I just tested this
with gfortran on Linux, configuring a netCDF-C library with --disable-netcdf-4
(equivalent to not setting CPPFLAGS and LDFLAGS to point to an installed HDF5
library) and got similar errors from gfortran:

  Making all in fortran
  make[2]: Entering directory 
`/machine/russ/git/netcdf-fortran/.build-v44-v4-v2/fortran'
  gfortran -DHAVE_CONFIG_H -I. -I../../fortran -I.. -I../libsrc   
-I/machine/russ/installs/nc432-nc4-v2/include  -g -O2 -c -o 
module_netcdf_nc_data.o ../../fortran/module_netcdf_nc_data.F90
  gfortran  -g -O2 -c -o module_netcdf_nc_interfaces.o  
../../fortran/module_netcdf_nc_interfaces.f90
  gfortran -DHAVE_CONFIG_H -I. -I../../fortran -I.. -I../libsrc   
-I/machine/russ/installs/nc432-nc4-v2/include  -g -O2 -c -o 
module_netcdf_nf_data.o ../../fortran/module_netcdf_nf_data.F90
  gfortran -DHAVE_CONFIG_H -I. -I../../fortran -I.. -I../libsrc   
-I/machine/russ/installs/nc432-nc4-v2/include  -g -O2 -c -o 
module_netcdf_nf_interfaces.o ../../fortran/module_netcdf_nf_interfaces.F90
  gfortran  -g -O2 -c -o module_netcdf_f03.o  
../../fortran/module_netcdf_f03.f90
  gfortran  -g -O2 -c -o typeSizes.o  ../../fortran/typeSizes.f90
  gfortran  -g -O2 -c -o netcdf.o  ../../fortran/netcdf.f90
  netcdf_overloads.f90:13.52:
      Included at ../../fortran/netcdf.f90:48:

                       nf90_def_var_fill_FourByteReal, &
                                                      1
  Error: Procedure 'nf90_def_var_fill_eightbytereal' in generic interface 
'nf90_def_var_fill' at (1) is neither function nor subroutine
  netcdf_overloads.f90:22.52:
      Included at ../../fortran/netcdf.f90:48:

                       nf90_inq_var_fill_FourByteReal, &
                                                      1
  Error: Procedure 'nf90_inq_var_fill_eightbytereal' in generic interface 
'nf90_inq_var_fill' at (1) is neither function nor subroutine
  netcdf_text_variables.f90:60.93:
      Included at ../../fortran/netcdf.f90:56:

So netcdf-fortran v4.4.0 *requires* a netCDF-4 C library.  I think this is a 
change from the previous 
versions of netcdf-fortran, which built OK even using just a netCDF-3 C 
library.  There may be many 
netcdf-fortran users who still only need the netCDF-3 Fortran API, but for now 
a workaround is to 
require a netCDF-4 C library even in that case.  I'm not sure how difficult it 
would be to fix this ...

> On 07/16/2014 03:09 PM, Unidata netCDF Support wrote:
> > Hi Sang-Mi,
> >
> >> I encountered errors while installing netcdf-fortran-4.4.0 using intel 
> >> compilers (ifort and icc) on RedHat Linux Os version 5.9. The errors I 
> >> have appeared in both './configure' and 'make install'.  The first stage 
> >> is re-directed in 'config.log' in which it complained as below:
> >>
> >> --------------------------------------------------------------------------------------------------------------------------
> >> icc: warning #10237: -lcilkrts linked in dynamically, static library not 
> >> available
> >>
> >> configure:4978: checking whether we are using the GNU Fortran compiler
> >> configure:4991: ifort -c   conftest.F >&5
> >> conftest.F(3): error #5082: Syntax error, found END-OF-STATEMENT when 
> >> expecting one of: ( % [ : . = =>
> >> choke me
> >> ---------------^
> >> conftest.F(3): error #6218: This statement is positioned incorrectly 
> >> and/or has syntax errors.
> >> choke me
> >> ---------------^
> >> compilation aborted for conftest.F (code 1)
> >> configure:4991: $? = 1
> >> configure: failed program was:
> >> |       program main
> >> | #ifndef __GNUC__
> >> |        choke me
> >> | #endif
> >> |
> >> |       end
> >> --------------------------------------------------------------------------------------------------------------------------
> >
> > The above is not a symptom of a problem when you are using ifort.  It is 
> > expected
> > when running configure, as part of determining that the Fortran compiler is 
> > not
> > gfortran.
> >
> >> The second step, 'make check' yielded the following errors:
> >>
> >> [IRIS8]/pln1/local/netcdf-fortran-4.4.0> make check
> >> Making check in fortran
> >> make[1]: Entering directory `/pln1/local/netcdf-fortran-4.4.0/fortran'
> >> ifort  -g -c -o netcdf.o  netcdf.f90
> >> netcdf_overloads.f90(9): error #7950: Procedure name in MODULE PROCEDURE 
> >> statement must be the name of accessible module procedure.   
> >> [NF90_DEF_VAR_FILL_ONEBYTEINT]
> >> module procedure nf90_def_var_fill_OneByteInt,   &
> >> ---------------------^
> >> netcdf_overloads.f90(10): error #7950: Procedure name in MODULE PROCEDURE 
> >> statement must be the name of accessible module procedure.   
> >> [NF90_DEF_VAR_FILL_TWOBYTEINT]
> >> nf90_def_var_fill_TwoByteInt,   &
> >> ---------------------^
> >> netcdf_overloads.f90(11): error #7950: Procedure name in MODULE PROCEDURE 
> >> statement must be the name of accessible module procedure.   
> >> [NF90_DEF_VAR_FILL_FOURBYTEINT]
> >> nf90_def_var_fill_FourByteInt,  &
> >> ---------------------^
> >
> >  From the config.log, I see the version of ifort is:
> >
> >     configure:4958: ifort --version >&5
> >     ifort (IFORT) 14.0.2 20140120
> >
> > This is a recent enough version that I would expect it would support the
> > overloading that's happening in the netcdf_overloads.f90 statments
> > where it's getting errors.  The config.log also shows your ifort supports
> > Fortran 2008 ISO_FORTRAN_ENV additions, but not the TS29113 standard
> > extension.
> >
> > We didn't test this release with ifort at Unidata.  We do have access
> > to an Intel Fortran development environment on a remote platform
> > where we may be able to reproduce the problem, but that will take some
> > time.  In the meantime, I'm also forwarding this question to the developer,
> > Richard Weed, who tests on Intel Fortran as well as gfortran, in case he
> > has time to diagnose the problem ...
> >
> > Richard, I've made the config.log and make.check.log available here, in
> > case you need them:
> >
> >    
> > https://drive.google.com/file/d/0Bzp7-lBkQPZ5a1o3bl9rdVE5Nm8/edit?usp=sharing
> >    
> > https://drive.google.com/file/d/0Bzp7-lBkQPZ5ZEt5RkkwTjFtVDA/edit?usp=sharing
> >
> > Thanks for any help you can provide!
> >
> > --Russ
> >
> >> Logs files from the two steps are attached.
> >> Any help will be greatly appreciated.
> >>
> >> Sincerely,
> >>
> >> Sang-Mi Lee, Ph.D.
> >> Program Supervisor - Air Quality Modeling
> >> South Coast Air Quality Management District
> >> Phone: 909-396-3169
> >> Fax: 909-396-3252
> >
> > Russ Rew                                         UCAR Unidata Program
> > address@hidden                      http://www.unidata.ucar.edu
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: YYO-369400
> > Department: Support netCDF
> > Priority: Normal
> > Status: Closed
> >
> 
> --
> ---
> -----
> 
> Richard Weed, Ph.D.
> Associate Research Professor
> Center for Advanced Vehicular Systems (CAVS)
> Mississippi State University
> 
> email: address@hidden
> Phone: (662) 325-5450
> 
> 
Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: YYO-369400
Department: Support netCDF
Priority: Normal
Status: Closed