Sang-Mi
A fix to the problem you encountered with netCDF-Fortran version 4.4.0,
contributed
by Richard Weed, is now available in the developers' snapshot from GitHub:
https://github.com/Unidata/netcdf-fortran
or you can wait for the release of version 4.4.1, which will be available soon.
--Russ
> On 07/17/2014 11:27 AM, Sang-Mi Lee wrote:
> > Hi Richard and Russ,
> >
> > Yes, I did compile netcdf C with --disable-netcdf4 option. Here is the
> > config.log from netcdf-C installing. I will see if I can enable netcdf4
> > function.
> >
> > It is not clear what cause the error with 'sizeof'. Warning/error message
> > appears after the 'sizeof' is listed below. Also attached is 'config.log'
> > from netcdf-4.3.2
> >
> > --------------------------------------------------
> > conftest.c(89): error: expected an expression
> > if (sizeof ((_Bool)))
> > ^
> >
> >
> > icc: warning #10237: -lcilkrts linked in dynamically, static library not
> > available
> > /tmp/icckFwzuj.o: In function `main':
> > conftest.c:(.text+0x33): undefined reference to `strlcat'
> > configure:15181: $? = 1
> > configure: failed program was:
> > | /* confdefs.h */
> >
> > ----------------------------------------------------
> >
> >
> > Thank you very much for your help and please keep me posted.
> >
> > Sang-Mi Lee, Ph.D.
> > Program Supervisor - Air Quality Modeling
> > South Coast Air Quality Management District
> > Phone: 909-396-3169
> > Fax: 909-396-3252
> >
> >
> > -----Original Message-----
> > From: Unidata netCDF Support [mailto:address@hidden
> > Sent: Thursday, July 17, 2014 7:41 AM
> > To: Sang-Mi Lee
> > Cc: address@hidden; address@hidden; Sang-Mi Lee
> > Subject: [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
> >
>
> --
> ---
> -----
>
> 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: High
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.