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.
>From: Dave Parker <address@hidden> >Organization: SSEC >Keywords: 200204152102.g3FL2fa10111 McIDAS netCDF 3.5 Dave, >Tom, thank you for the suggestions. We had tried using the >-Df2cFortran flag before, with the same results. I did try again from >a clean install--just to be sure. Here is the output: > >Making `all' in directory /home1/mcidas/mcidas7.811/netcdf/fortran > > gcc -c -O -I../libsrc -DNDEBUG -Df2cFortran fort-attio.c >In file included from fort-attio.c:6: >ncfortran.h:27:42: NF_INT_IS_C_... not defined: A file or directory in the pat > h name >does not exist. OK. This is telling us that the size of C constructs used for Fortran integer, integer*2, etc. was not set during the configure step of the build. In order to troubleshoot this, we need the config.log file that you should find in the netcdf directory of your package (~/mcidas7.811/netcdf ?). What we really need, but what you probably don't have is the output from configure while it is running. This would tell us exactly what didn't get set AND may, in fact, make some comment about why it didn't get set. The netCDF instructions usually tell folks to trap the configure output by redirecting stdio and stderr into a file called configure.log. Since you are building using the script approach, this might be more difficult to do (I do not use the script build construct bundled with SSEC McIDAS as it makes life too difficult when things like the problem you are reporting occur) >fort-attio.c:12: parse error before "NF_INTEGER" >fort-attio.c:12: parse error before '*' token >fort-attio.c:12: parse error before numeric constant >fort-attio.c:12: warning: data definition has no type or storage class >fort-attio.c:12: parse error before numeric constant >fort-attio.c:12: parse error before '!' token >fort-attio.c:12: parse error before numeric constant >fort-attio.c:19: parse error before numeric constant ><snip> > >I believe the main changes since our last successful build are a new >version of gcc (3.0.1 on AIX 4.3) and the netcdf-3.5.0.tar.Z >distribution from unidata. I talked with the primary netCDF developers here, and they commented that there is no known problem building with gcc 3.0.1, at least not in the section where you are seeing a problem. They also commented that if you are using the C++ interface, that the best netCDF distribution to use would be the netcdf-3.5.1-beta.tar.Z as it fixed some known problems. To reiterate, we have not seen a problem like the one you are reporting when building 3.5.x using gcc 3.0.1. >Here is the environment that exists right >before the 'make' command is issued from within the mcidas install >script: > > _=/usr/bin/env > LANG=en_US > NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat > IMQCONFIGCL=/etc/IMNSearch/dbcshelp > SSH_TTY=/dev/pts/4 > PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:/home1/mcidas/bin:/usr/bin/X11:/sbin:/ > usr/ > local/bin:.:/home1/mcidas/mcidas7.811/src > LC__FASTMSG=true > CGI_DIRECTORY=/var/docsearch/cgi-bin > IMQCONFIGSRV=/etc/IMNSearch > LOGNAME=mcbeckys > MAIL=/usr/spool/mail/mcbeckys > LOCPATH=/usr/lib/nls/loc > USER=mcbeckys > DOCUMENT_SERVER_MACHINE_NAME=localhost > AUTHSTATE=compat >* CC=gcc >* CXX=g++ > McINST_ROOT=/home1/mcidas > SHELL=/bin/ksh > ODMDIR=/etc/objrepos >* CPPFLAGS=-DNDEBUG -Df2cFortran > DOCUMENT_SERVER_PORT=49213 > HOME=/home1/mcidas >* FC=mcfc > SSH_CLIENT=128.104.110.150 53595 22 > TERM=vt100 > MAILMSG=[YOU HAVE NEW MAIL] > PWD=/home1/mcidas/mcidas7.811/src > DOCUMENT_DIRECTORY=/usr/docsearch/html > TZ=CST6CDT > McIDAS_ROOT=/home1/mcidas > A__z=! LOGNAME > >I talked to BeckyS about this, and she suggested that you may want to >use our AIX machine Sweetpea to test since the error is not showing up >on your AIX box. The contents of the config.log (and configure.log if you can create it) would be the best thing in this case. >The .tar.Z file we are using is >/home1/mcidas/mcidas7.811.tar.Z, and the install script is >/home1/mcidas/mcidas7.811.sh. The command I am using to start the make >is "sh mcidas7.811.sh -gcc -noopt make" Would it be possible for me to get a login as you so I could look at the exact setup you are using? This may be the quickest way to find the problem. Tom >From address@hidden Fri Apr 19 08:48:21 2002 >To: Unidata Support <address@hidden> >CC: address@hidden >Subject: Re: 20020416: NetCDF 3.5 build errors on AIX under McIDAS (cont.) Tom, we have succesfully built NetCDF 3.5.0 with the McIDAS install script on AIX. I took your advice and looked at the NetCDF config.log file, which showed errors building the test programs with 'mcfc' as follows (similar lines for each data type, using "signed char" as an example here): configure:1933: checking if Fortran "byte" is C "signed char" configure:1942: gcc -c -DNDEBUG -O conftest.c configure:1944: mcfc -c conftestf.f conftestf.f: MAIN: configure:1946: mcfc -o conftest conftestf.o conftest.o ld: 0711-317 ERROR: Undefined symbol: .__main ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status configure:1948: ./conftest configure[1947]: ./conftest: not found I added the -bnoquiet option, and found that libgcc.a was not being found, even though it exists in /usr/local/lib, along with libf2c.a which was in fact being found and loaded. In the 'mcfc' script I added a line which reads: lOPTS="$lOPTS -lgcc -L$LIBDIR" so that the linker is explicitly told where to find libgcc.a. $LIBDIR in this case point to wherever libf2c.a is found (set up earlier in the 'mcfc' script). One other problem that I found with our install script (which was greatly complicating matters) is that the path to my modified 'mcfc' is appended to the current path, instead of prepended as it should be. So even after making the modifications, users with another 'mcfc' in their path were still seeing errors. After sorting this out, we dont appear to be having any more trouble with NetCDF. Thank you very much for your help! I couldnt have tracked this one down without your suggestions. -DaveP