- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 MathFuncs.c
NclDataDefs.h(122): error: "compound" has already been declared in the current scope
typedef int compound;
^
compilation aborted for MathFuncs.c (code 2)
make[4]: *** [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?
.
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 MathFuncs.c
NclDataDefs.h(122): error: "compound" has already been declared in the current scope
typedef int compound;
^
compilation aborted for MathFuncs.c (code 2)
make[4]: *** [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?
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
[Speaking for myself, not Intel]
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Does that help?
Dale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this problem resolved by now?
I just ran into the same problem and got it figured out, i.e. found the right resources.
I have (k)ubuntu 11.04 64bit and composerxe-2011.4.191.
To solve the problem described above, I had to chance some occurences of 'compound' to 'nclcompound' in the files 'NclDataDefs.h' and 'DataSupport.c' (in$NCARG/ni/src/ncl/) as described in this NCL mailing list post: http://www.ncl.ucar.edu/Support/install_archives/2011/0133.html
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.
I hope this is useful to someone...
Andre
I just ran into the same problem and got it figured out, i.e. found the right resources.
I have (k)ubuntu 11.04 64bit and composerxe-2011.4.191.
To solve the problem described above, I had to chance some occurences of 'compound' to 'nclcompound' in the files 'NclDataDefs.h' and 'DataSupport.c' (in$NCARG/ni/src/ncl/) as described in this NCL mailing list post: http://www.ncl.ucar.edu/Support/install_archives/2011/0133.html
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.
I hope this is useful to someone...
Andre
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
I will continue testing...
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.
I will continue testing...

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page