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