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

Re: 20020119: problems compiling netcdf for Fortran 90

>To: <address@hidden>
>From: Matt Brennan <address@hidden>
>Subject: problems compiling netcdf for Fortran 90
>Organization: Dept. of Civil & Environmental Engineering,  Stanford University
>Keywords: 200201191707.g0JH7fx09738, Linux, Intel Fortran compiler

Matt,

> Thanks for your trouble shooting.  I hadn't realized that the f90 code
> depended on the f77 code.  In the mean time, I've been working on
> installing pre-compiled binaries as an alternate way to implement netCDF.
> But I've reached a sticking point on this path too.  Could you check out
> both of the paths I'm working on and pass on your advice about which path
> I should pursue and how I might get unstuck?
> 
> Installing the binaries
> ***********************
> 
> Before I received your response, I started working on an alternate
> solution.  I downloaded the netcdf Linux binaries from the webpage
> http://www.unidata.ucar.edu/packages/netcdf/binaries.html. I then tested
> these binaries using the ftest code included with the netCDF source.
> These binaries worked successfully with the ftest program included in the
> netCDF source and compiled with my compiler, the Intel Fortran Compiler.
> 
> However, the binaries won't work with the program that I'm ultimately
> interested in using.  This program, GOTM, is a numerical water column
> model written in Fortran 90.  However, judging from the GOTM source, this
> program still uses the f77 implementation of netCDF, i.e. it does relies
> on 'include netcdf.inc' to include the netCDF functions and not the 'use
> netcdf' format for f90 modules.
> 
> The errors I get when I try to compile GOTM with the Intel compiler,
> including the netCDF library on the compiler path, occur at the linking
> stage.  The linker can't seem to find the netCDF object files.  The errors
> (lots of them!) are of the form:
> 
> ncdfout.o(.text+0x3cdf): undefined reference to `nf_put_att_text_'
> ncdfout.o(.text+0x3d28): undefined reference to `nf_put_att_real_'
> 
> where ncdfout.o is the object file of GOTM that conducts the netCDF
> output.  These are similar types of error that I get if I compile ftest
> without specifying the path for the netCDF library.  But I'm puzzled as
> to why the compiler/linker can find the netCDF library in one case but
> can't seem to find it in the other.  Any suggestions?
> 
> While trying to figure out the problem, I stumbled across a technical
> note from Intel discussing linking of object files created by different
> compilers.
> http://support.intel.com/software/products/compilers/c50/linux/CompilersCompatibility2.pdf.
> This document warns against linking object files created by different
> compilers.  It explicity says that linking with object files created by
> g77 won't work.  Do you know what compiler was used to create the binaries
> on the unidata web site?  Do you think I should be concerned about this
> inter-compiler issue even if the ftest program worked when compiled with
> the Intel compiler?

Yes, you've been tripped up by a problem with binary distributions for
Fortran libraries: they don't work in general when used with different
compilers than were used to build the binary distributions.  Our
collection of binary distributions (only one per platform) also
doesn't include the information needed to determine what compiler and
which compiler flags were used in building the binary, necessary to
determine how to compile and link an application against the library.
(We are discussing how to best provide this information.)

The Linux binary distribution you downloaded was built with g77, so
won't work with applications compiled with the Intel compiler.  And we
currently don't have the Intel compiler installed on a Linux platform
(though you've pointed out that a free evaluation copy exists).  There
are some other binary distributions of netCDF for Linux available in
the form of .rpm files or Debian dpkg distributions, but these would
also only work with a matching Fortran compiler, and I think they are
built with g77.  So I think you will have to build from source.

> Installing from the source code
> *******************************
> 
> I returned to the problem of installing netCDF from the source with more
> knowledge:  your advice about the f90 installation; the warnings of
> inter-compiler linking mentioned above; and the realization that the
> modeling code does not require the f90 implementation of netCDF.  So I set
> the environmental variables to identifiy the Intel compiler as the f77
> compiler and tried to compile the f77 netCDF libraries from the source.
> This produced errors in the make stage.  It seems that the c preprocessor
> doesn't recognize the system.  The log files are listed below.
> 
> Do you think I should continue to try and install from the source or will
> the binaries be sufficient?

 ...

> `/home/mbrennan/downloads/netcdf/netcdf-3.5.0/src/fortran'
> 
> gcc -c -O -I../libsrc  -DNDEBUG fort-attio.c
> In file included from ncfortran.h:13,
>                  from fort-attio.c:6:
> 
> cfortran.h:134:3: #error "cfortran.h:  Can't find your environment among:
> - MIPS cc and f77 2.0. (e.g. Silicon Graphics, DECstations, ...)  - IBM
> AIX XL C and FORTRAN Compiler/6000 Version 01.01.0000.0000 - VAX VMS CC
> 3.1 and FORTRAN 5.4.  - Alpha VMS DEC C 1.3 and DEC FORTRAN 6.0.  - Alpha
> OSF DEC C and DEC Fortran for OSF/1 AXP Version 1.2 - Apollo DomainOS 10.2
> (sys5.3) with f77 10.7 and cc 6.7.  - CRAY - NEC SX-4 SUPER-UX - CONVEX -
> Sun - PowerStation Fortran with Visual C++ - HP9000s300/s700/s800 Latest
> test with: HP-UX A.08.07 A 9000/730 - LynxOS: cc or gcc with f2c.  -
> VAXUltrix: vcc,cc or gcc with f2c. gcc or cc with f77.  - f77 with vcc
> works; but missing link magic for f77 I/O.  - NO fort. None of gcc, cc or
> vcc generate required names.  - f2c : Use #define f2cFortran, or cc
> -Df2cFortran - NAG f90: Use #define NAGf90Fortran, or cc -DNAGf90Fortran -
> Absoft UNIX F77: Use #define AbsoftUNIXFortran or cc -DAbsoftUNIXFortran -
> Absoft Pro Fortran: Use #define AbsoftProFortran - Portland Group Fortran:
> Use #define pgiFortran"
> 
> make[2]: *** [fort-attio.o] Error 1

The netCDF Fortran interface is implemented by calling C functions.
Unfortunately, there is no standard specifying how Fortran calls C
functions, and there are many compiler/vendor variations.  We depend
on the "cfortran.h" solution of Burkhard Burow for implementing the
Fortran/C interface:

  http://www-zeus.desy.de/~burow/cfortran/

The users guide for cfortran.h at

  http://www-zeus.desy.de/~burow/cfortran/cfortran.html

doesn't indicate support for the Intel ifc compiler yet.

When a new Fortran compiler such as Intel's ifc is introduced, it can
be used with "cfortran.h" without modification only if it uses one of
the existing conventions for the Fortran/C interface.  These
conventions include how strings arguments are passed from Fortran to C
and how functions in C are named from Fortran (e.g. by appending or
prepending "_").  If your Intel Fortran compiler has documentation on
interfacing Fortran and C, and it uses the same conventions as another
compiler, then you might only need to include the right C compiler
flag, for example "CFLAGS=-Df2cFortran" if it uses the same
conventions as the f2c or g77 compilers.  If you're lucky, one of
these might just work:

  -DDECFortran
  -Dlynx
  -DhpuxFortran800
  -Df2cFortran
  -DpgiFortran
  -DNAGf90Fortran
  -DAbsoftUNIXFortran
  -DAbsoftProFortran
  -DCLIPPERFortran

I'll contact Burkhard Burow <address@hidden> to see if he knows how to
support the Intel ifc compiler with cfortran.h.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu