NetCDF is your friend

(This page is "kept alive" for historical purposes, please do not contact me about Lahey 7.0 or greater and NetCDF issues)



How to compile NetCDF for Lahey F95 (pre v7) for linux and Win32. For versions of Lahey v7 and later one should be able to link in the precompiled MSVC libraries available at UNIDATA as Lahey now uses the MicroSoft Incremental Linker instead of the PharLap linker. Of course I can not validate this at this time (Feb 25 2003) as I have not tried it nor do I plan to as I no longer work with F95 codes.

LINUX last update: Oct 25 2001

    OK so the title may be stretching the truth a bit. Anyway here is how to make sure that NetCDF compiles for you if you use Lahey under linux. This comes courtesy of Dr. Roelof Versteeg at Columbia University's Lamont-Doherty Earth Observatory. This comes with no guarantee and only has come about due to some late night efforts by Dr. Versteeg so please do not ask him or me for details on how to compile NetCDF. If you have questions about NetCDF please contact UNIDATA via http://www.unidata.ucar.edu/packages/netcdf/index.html

    First for some minor details. It is assumed that lf95, gcc, and g++ are in your search path. It is also assumed that you are familiar with UNIX and how to compile/install software.

    Now on to the real stuff.
  1. Download the most recent source for NetCDF, we suggest netcdf-3.5-beta6 or higher, into your working directory. You can get it from ftp://ftp.unidata.ucar.edu/pub/netcdf and then:

        uncompress netcdf-3.5-beta6.tar.Z (you may not have to do this)
        tar xvf netcdf-3.5-beta6.tar
        cd netcdf-3.5-beta6
        cd src

  2. Set the following environment values:

    For Lahey F95 5.5
        FC=lf95
        CC=gcc
        CPPFLAGS='-DNDEBUG -DpgiFortran'
        CXX=g++
        FFLAGS=-I/usr/local/include

    For Lahey F95 6.0
    (we use the f77 hooks not the f90 ones. Also there seems to be an issue with integer configuration and lf95 6.0 according to the configure/make results so it is a good thing that lf95 can use g77 libs)
        FC=g77
        CPPFLAGS='-DNDEBUG -DpgiFortran'

    The -I in FFLAGS could actually be set to any directory where you keep shared include files as it is effectively not used. The syntax will differ depending on the type of shell you are running. If you are running a bourne type shell (bash) then you'll do:

        export CC=gcc

    and if you are running a C type shell (csh, tcsh) then you'll do:

        setenv CC gcc

  3. Now run ./configure in the src directory. This sets up the installion bits based on your environmnet.

  4. Now run make in the src directory. This "makes" (compiles) the NetCDF libraries and binaries.

  5. At this point one could run make test, but there are a few problems. Dr. Versteeg has dealt with most of these, but as they do not impact the compiled libraries I have decided to omit those fixes.

  6. Now run make install in the src directory. This will place the libraries, include files, and binary files in their respective directories: ../lib, ../include, and ../bin.
    NOTE: you can change the default install directory, read the INSTALL and README files.
    The fix above already allows for the name mangling so you will not have to define the NetCDF functions as ML_EXTERNAL as the Lahey documentation would suggest. I have also found that it is better to link in the library references as objects rather than as a library:

    lf95 <your compile/link flags> <your objects> /you/shared/lib/path/libnetcdf.a -o program.exe

I do not know why this is, but it may just be an improper flag setting on my part.


BACK


WinNT/Win32 last update: Dec 8 2000

(This page is "kept alive" for historical purposes, please do not contact me about Lahey 7.0 or greater and NetCDF issues)


    I have finally figured out a way to compile NeCDF libs with Lahey F95 under Win32. It is assumed that you have Lahey of course as well as Microsoft Visual C++. I wish I had a GCC solution, but unfortunately that is not the case at this time, though in principle it should possible ala the Linux fix above. The Linux fix does work to an extent, however, linking is problematic. Now onto the fixes:
  1. Download the most recent source for NetCDF, we suggest netcdf-3.5-beta6 or higher, and the Microsoft Visual C++ nmake files to your working directory. You can get them from ftp://ftp.unidata.ucar.edu/pub/netcdf and ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/win32 respectively, then:

        unzip netcdf-3.5-beta6.ZIP (you may not have to do this)
        cp netcdf-3.5-beta5.win32make.ZIP netcdf-3.5-beta6
        cd netcdf-3.5-beta6
        unzip netcdf-3.5-beta5.win32make.ZIP (you may not have to do this)
        cd src

  2. Next you'll have to make some changes to the msofts.mak files both in the libsrc and fortran directories. In both files you'll have to remove the /MT in the COPT lines, you'll also have to add a forgotten !ELSE after # Release and replace "VISUAL_CPLUSPLUS" with "MSVClf95Fortran" in fortran/msofts.mak.

  3. Now we have to make a fix to fortran/cfortran.h. You'll need to add the line:

        #if !(defined(MSVClf95Fortran))

    before the line:

        /* if your compiler barfs on '#errors', replace # with the trigrapher for # */

    as well as add another #endif after the error text.

  4. Now do:

        nmake /f msofts.mak

    in libsrc and then in fortran.

  5. Now copy libsrc/netcdfs.lib and fortran/netcdf.inc to where you need them.

  6. Since we are using Microsoft Visual C++ in conjunction with Lahey we need to change all the externals in netcdf.inc to ml_external and when we link we have to use these compiler/linker flags:

        -mldefault msvc -ml msvc -staticlink -libpath <your library path> -lib netcdfs

    This forces Lahey to link with the MSVC linker. In principle one should only have to add the -ml msvc part, however, that does not seem to force all the internal naming so -mldefault msvc must also be added. Another issue that could surface is with certain nf_<funtion>s changing an internal multi-language definition. Why this happens I do not know and at present only <nf_strerror> seems to do this. My fix was to just replace it with a Fortran 95 function and of course I had to change netcdf.inc to reflect this exclusion.
I should note that we are using Microsoft Visual C++ 6.0 and are only interested in the static libraries and as such have not investigated other combinations.

BACK