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

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



Richard,

> I'll have to go back and look at the code but
> this might be due to where I put the mods
> for the var_fill routines. I don't remember
> if there is a #ifdef USE_NETCDF4 or equivalent
> around the logic in netcdf_overloads.f90. If it is
> the code should probably be moved out of the #ifdef
> block (or inserted into one).
> 
> On another matter, I tried to build the code
> last night on my Linux system at home using
> Intel 14.0.1 (aka Composer 2013 SP1) and got
> a weird configure error in hdf5 (8.11.1) as
> well as the NetCDF 4.3.2 C and Fortran 4.4.
> 
> For some reason icc is gagging on the sizeof (off_t) test
> for all three codes. For hdf5 and C 4.3.2, configure continues
> and generates the make files. However, Fortran 4.4 configure dies
> at the sizeof test so no make files are generated.
> 
> It's either something with icc 14.0.1 or the version of the
> autoconfig tools I have on my system

The sizeof(off_t) test often fails is just because of a problem linking
with a shared library, becasue it it sometimes the first test that uses
the LDFLAGS, LD_LIBRARY_PATH, and LIBS environment variables (if
the latter two exist) when running an executable involving the shared
object linke ld.so (on Linux).  You can see the real cause of the failure
by looking closely near the end of config.log at the actual error 
message before the size_t message, which is often something like 
couldn't find the shared object libnetcdf.so or libhdf5.so.

Feel free to send us the config.log, attached to a separate email to
address@hidden (Sang-Mi Lee may not be interested
in that problem).

--Russ

> If its icc there might also be other problems with this
> version of the Intel compilers. I'll try dropping back
> to Intel 13.1 when I get a chance.
> 
> RW
> 
> On 07/17/2014 07:30 AM, Unidata netCDF Support wrote:
> > 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
> >
> 
> --
> ---
> -----
> 
> 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.