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

20021209: NetCDF 64-bit Solaris build w/Fortran support

Russ,

[Mike, search for "runtime-support"]

>Date: Mon, 09 Dec 2002 14:24:40 -0700
>From: Russ Rew <address@hidden>
>Organization: UCAR Unidata Program
>To: Kevin Farnham <address@hidden>
>Subject: Re: 20021209: NetCDF 64-bit Solaris build w/Fortran support 

The above message contained the following:

> I don't know what flags to use with g77 to make it consistent with a C
> library built with gcc and CFLAGS=-m64.  I tried g77 with FFLAGS=-m64
> and CPPFLAGS=-Df2cFortran, but the resulting errors
> 
>   fort-attio.c:141: parse error before numeric constant
>   fort-attio.c:141: parse error before '!' token
>   fort-attio.c:141: parse error before numeric constant
>   fort-attio.c:148: parse error before numeric constant
>   fort-attio.c:148: warning: data definition has no type or storage class
>   ...
> 
> seem to indicate that something is wrong in the cfortran.h macros that
> tell how Fortran programs call C functions.  I'm CC:ing Steve Emmerson
> on this reply, in case he can determine whether we can get this
> combination working.

I was able to produce an error similar to the above:

    Making `all' in directory /home/steve/netcdf/fortran

    /opt/gnu/gcc3-sparc-5.8/bin/gcc -c -m64 -I../libsrc  -Df2cFortran
    fort-attio.c
    In file included from fort-attio.c:6:
    ncfortran.h:27:42: NF_INT_IS_C_... not defined: No such file or
    directory
    fort-attio.c:13: parse error before "NF_INTEGER"
    fort-attio.c:13: parse error before '*' token
    fort-attio.c:13: parse error before numeric constant

on my SunOS 5.8 system using the following:

    CC=/opt/gnu/gcc3-sparc-5.8/bin/gcc
    CFLAGS=-m64
    CPPFLAGS=-Df2cFortran
    FC=/opt/gnu/gcc3-sparc-5.8/bin/g77
    FFLAGS='-m64 -w'
    F90=''
    CXX=''

The compiler versions are

    $ /opt/gnu/gcc3-sparc-5.8/bin/gcc --version
    gcc (GCC) 3.2
    ...
    $ /opt/gnu/gcc3-sparc-5.8/bin/g77 --version
    GNU Fortran (GCC 3.2) 3.2 20020814 (release)
    ...

The "configure.log" file contained the following:

    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
    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

which indicates that the configure script couldn't find primitive
C types corresponding to primitive Fortran types. This is a severe
problem. The diagnostic error-message file "config.log" had this to say:

    ...
    configure:1959: checking if Fortran "byte" is C "signed char"
    configure:1968: /opt/gnu/gcc3-sparc-5.8/bin/gcc -c -Df2cFortran -m64 
conftest.c
    configure:1970: /opt/gnu/gcc3-sparc-5.8/bin/g77 -m64 -c conftestf.f
    configure:1972: /opt/gnu/gcc3-sparc-5.8/bin/g77 -o conftest -m64 
conftestf.o conftest.o  
    configure:1974: ./conftest
    ld.so.1: ./conftest: fatal: libg2c.so.0: open failed: No such file or 
directory
    Killed
    ...

So, apparently, our gcc installation doesn't know where it's
runtime-support libraries reside.  Pity.

Starting from scratch and setting the LD_RUN_PATH environment variable to
reference the GNU, 64-bit, runtime-support libraries:

    export LD_RUN_PATH=/opt/gnu/gcc3-sparc-5.8/lib/sparcv9

resulted in a successful build and test.

To recap: a successful, 64-bit build apparently requires the following:

    1.  LD_RUN_PATH containing the pathname of the directory that
        contains the 64-bit, GNU runtime libraries;

    2.  CFLAGS with "-m64"; and
    
    3.  FFLAGS with "-m64 -w";

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