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
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.