Ubuntu 10.04LTS with intel C++/Fortran XE Compilers . The problem is that I am unable to build NCL-NCAR graphics nodap. NCAR graphics is built but executable ncl is not. No ncl created in/usr/local/ncarg/bin
here is the error I am getting. The guys at NCAR has never seen this problem and cannot help me. Can u help.
icc -ansi -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-I/usr/local/include -O -I../../.././include -I/usr/local/include
-I/usr/include -DLinux -DMAJOR=2 -DSYSV -D_POSIX_SOURCE
-D_XOPEN_SOURCE -DByteSwapped -DNeedFuncProto -c -o MathFuncs.o
NclDataDefs.h(122): error: "compound" has already been declared in the current scope
typedef int compound;
compilation aborted for MathFuncs.c (code 2)
make: *** [MathFuncs.o] Error 2
Side note. As a backup is it possible to ge the older compilers and where to I do to get them?
It is unlikely that Intel will support the porting of large, complex third party codes of mixed pedigree and vintage.
See this Troubleshooting list at the NCAR site. First, see if you can build NCL-NCAR using GCC instead of Intel C. Then, if you can narrow down the problem and show short example code with which you can demonstrate that Intel C cannot compile code that is accepted by GCC, something could be done.
Before you try an older version of Intel C, I suggest, try building with GCC.
To download an older compiler, login to the Registration center and choose the product. There are two boxes that show the major and minor release numbers, initially showing the current compiler. Choose an earlier version as desired by clicking in those boxes.
There are a couple of possibilities if you want to track this problem down, assuming it builds with gcc. The first thing I would do would be to create a ".i" file (essentially add -E to the command line and capture the output). Then check to see if "compound" is declared twice as indicated by the error message. Then I would compare that against a .i file generated by gcc and see if it's defined twice there as well. If that is different, then there may be some #if guarding something for one compiler but not the other. If it's also defined twice in the gcc generated .i, you may be able to make a a small test case that illustrates the difference and post it here and we can advise.
Then I had to change all calls to 'abort' ('call abort') to 'stop' (just the statement, no 'call'). 'abort' is a built-in subroutine in gfortran, which is not available in ifort ('stop' works instead).
Finally I had to use the following line for the CtoFLibraries: '-lm -L/opt/intel/composerxe-2011.4.191/compiler/lib/intel64/ -lifcore -lirc -lifport' This is to avoid some undefined-symbol-errors.
After all that it compiles alright and can reproduce the two test cases suggested on their website. I haven't tested it extensively yet.
While I'm at it, has anyone of you guys experimented with optimization?
I just recompiled (after clean) with '-O3 -xhost' (standard is '-O2'); the compilation terminated somewhere in the blas-related part. I recompiled (after clean) using '-O2 -xhost'; this time I got a couple of 'Error 127', mostly in math-related libraries, but ncl itself seems to work fine and passes the two tests above.