[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netCDF #YYO-369400]: netcdf-fortran-4.4.0 installation error
- Subject: [netCDF #YYO-369400]: netcdf-fortran-4.4.0 installation error
- Date: Mon, 28 Jul 2014 20:12:49 -0600
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