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

Re: 19991207: "make nf_test/test" failure: Red Hat Linux 6.1: fort77

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: 19991207: "make nf_test/test" failure: Red Hat Linux 6.1: fort77
  • Date: Tue, 07 Dec 1999 10:00:58 -0700
Dean,

> To: address@hidden
> From: "Dean N. Williams" <address@hidden>
> Subject: "make test" Fails!
> Organization: PCMDI
> Keywords: 199912071402.HAA12184

In the above message, you wrote:

> Platform: Red Hat Linux 6.1
> 
> "uname -a":
>     Linux chico 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown
> 
> VERSION:
> 3.4
> 
> compilers (C, Fortran, C++):
> %which cc gcc c++ g++ f77 g77 fort77
> /usr/bin/cc
> /usr/bin/gcc
> /usr/bin/c++
> /usr/bin/g++
> /usr/bin/f77
> /usr/bin/g77
> /usr/bin/fort77
> %
> 
> "configure.log", "make.log", "test.log":
> 
>     SEE ATTACHED FILES
> 
> --
> Dean N. Williams
> Computer Scientist/Computation Group Leader             o
> Lawrence Livermore National Laboratory                --
> Livermore, California 94550                          `\< *
> Phone: (925) 423-0145    FAX: (925) 422-7675        /  \
> http://www-pcmdi.llnl.gov                         address@hidden
> 
> 
>  filename="config.log"
...

I didn't see anything in "config.log" that would indicate a problem.

>  filename="configure.log"
> 
> creating cache ./config.cache
> checking for m4... m4
> checking user-defined C compiler "/usr/bin/cc"
> checking C compiler... works
> checking how to make dependencies... false
> checking for /usr/bin/c++... /usr/bin/c++
> checking C++ compiler "/usr/bin/c++"... works
> checking how to run the C preprocessor... /usr/bin/cc -E
> checking user-defined Fortran compiler "/usr/bin/fort77"... works
> checking for Fortran .F compiler... 
> checking if Fortran compiler handles *.F files... yes
> checking for C-equivalent to Fortran routine "SUB"... sub_
> checking for Fortran "byte"... yes
> checking for Fortran "integer*2"... yes
> checking if Fortran "byte" is C "signed char"... no
> checking if Fortran "byte" is C "short"... no
> checking if Fortran "byte" is C "int"... no
> checking if Fortran "byte" is C "long"... no

Whoa!  The Fortran "byte" type doesn't correspond to any C type!?

> 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

And the same goes for "integer*2", "integer", "real", and
"doubleprecision"?!

Needless to say, your Fortran interface will be useless because there
will be no way to convert between Fortran data types and the C data
types used in the underlying library.  This is probably the cause of the
segmentation fault during execution of the "make test" in the nf_test/
subdirectory.

This doesn't happen on our system:

    $ uname -a
    Linux sunshine.unidata.ucar.edu 2.2.13 #5 SMP Mon Nov 29 12:41:02 MST 1999 
i686 unknown

We'll need to discover why it happens on yours.

On our system, the "fort77" compiler's pathname is "/opt/bin/fort77"
while on your system it's "/usr/bin/fort77".  I wonder if they're the
same compiler.  Here's our version:

    $ fort77 -v
    /opt/bin/fort77: fort77 Version 1.14a
    /opt/bin/fort77: No input files specified

What's your version?

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