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

Re: 19981026: netCDF on T3D/E

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 19981026: netCDF on T3D/E
  • Date: Fri, 30 Oct 1998 11:25:58 -0700
Al,

> Date:    Thu, 29 Oct 1998 16:19:47 -0500
> From:    Al Bourgeois <address@hidden>
> To:      Russ Rew <address@hidden>, Al Bourgeois <address@hidden>
> Keywords: 199810292226.PAA24396
> Subject: netCDF on T3D/E

In the above message, you wrote:

> I tried unsuccessfully to install netCDF 3.4 on our T3D. As a control
> test, I tried it on our C90 and everthing seemed to work fine. On the
> T3D, the compilation dies with:
> 
>         cc -c -O -I../libsrc  -DNDEBUG fort-attio.c
> cc-315 cc: ERROR fort-attio.c, Line = 6, File = ./ncfortran.h, Line = 27
>   The include file "NF_INT_IS_C_... not defined" is unavailable.
> 
> which I realize is because the check for Fortran "integer" failed (see
> below) during the configuration stage. As you can see below, the mapping
> from Fortran to C seems to fail completely, since everthing results in a
> "no". For example, the Fortran "real" should map to a C "double". I
> don't know why the conftests fail on the T3D but not on the C90. I could
> hardwire the NF_INT_IS_C_ flags in nfconfig.inc, but I am worried that
> since the conftests aren't working, that something is wrong in my setup.
> Any ideas?
> 
> checking how to run the C preprocessor... (cached) cc -E
> checking user-defined Fortran compiler "cf77"... works
> checking for Fortran .F compiler... 
> checking if Fortran compiler handles *.F files... no
> checking for Fortran preprocessor... cc -E
> checking for C-equivalent to Fortran routine "SUB"... SUB
> checking for Fortran "byte"... no
> checking for Fortran "integer*1"... yes
> checking for Fortran "integer*2"... yes
> checking if Fortran "integer*1" is C "signed char"... no
> checking if Fortran "integer*1" is C "short"... no
> checking if Fortran "integer*1" is C "int"... no
> checking if Fortran "integer*1" is C "long"... no
> checking if Fortran "integer*2" is C "short"... no
> checking if Fortran "integer*2" is C "int"... no
> checking if Fortran "integer*2" is C "long"... no
> checking if Fortran "integer" is C "int"... no
> checking if Fortran "integer" is C "long"... no
> checking if Fortran "real" is C "float"... no
> checking if Fortran "real" is C "double"... no
> checking if Fortran "doubleprecision" is C "double"... no
> checking if Fortran "doubleprecision" is C "float"... no
> checking for Fortran-equivalent to netCDF "byte"... integer*1
> checking for Fortran-equivalent to netCDF "short"... integer*2

It appears that the configure script thinks that it's impossible
to build the Fortran interface *at all*.

I think some questions are in order:

    1.  Do you need the Fortran interface?

    2.  If so, then
    
        A.  What are the Fortran types that are equivalent to the
            following C types:

                signed char
                short
                int
                long
                float
                double

        B.  Would you please send me a copy of the file "config.log" 
            in the top-level source directory.

--------
Steve Emmerson   <http://www.unidata.ucar.edu>