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

20020416: NetCDF 3.5 build errors on AIX under McIDAS (cont.)

>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