Top posting since this is a bit different (but still related - so kept original stuff for reference if needed)
** also note I've rebooted into the 'testing' 2.4.27-1-686 kernel (ie so not to confuse issues with having downloaded the SMP kernel from backports)
1) I didn't use the netCDF .deb but rather downloaded the latest from the UCAR web site (netcdf-3_6_0-beta6).
2) I think the initial issues I should sort out are relating to the Intel 8.1 compilers (as opposed to netCDF)
3) I have two machines, say "home" and "work" which behave differently when I do the same Intel compiler installation. (I'll give details of the systems after describing the issues.) The Intel compiler installation was following Intel's instructions (alien; dpkg; amend the scripts)
4) For a simple C++ program
#include <iostream>
using namespace std;
int main() { cout << "sizeof(char)" << sizeof(char) << "\n"; cout << "sizeof(int)" << sizeof(int) << "\n"; cout << "sizeof(float)" << sizeof(float) << "\n"; cout << "sizeof(double)" << sizeof(double) << "\n"; }
the "home" 'icc' compiles, links and runs it without a problem and without the requirement of additional compiler flags. However, the "work" 'icc' requires the '-cxxlib-icc' flag, otherwise it produces the error
simple.cpp(1): catastrophic error: could not open source file "iostream"
The same is true if 'icpc' is used instead of 'icc'.
5) Linking seems another problem. This time the example is from (the
downloaded UCAR) netCDF, but it's a question about the Intel compilers.
It seems that you have to use 'icpc' and not 'icc' (fair enough!) but
the former still only works on my "home" machine, whereas on "work" the
first few errors are:
[EMAIL PROTECTED]:~/src/netcdf-3_6_0-beta6/src/cxx$ icpc -o nctst -g -O2
nctst.o libnetcdf_c++.a -L../libsrc -lnetcdf 2>&1 | less
nctst.o(.text+0xa3a): In function `__sti__$E':
/opt/intel_cc_80/include/c++/iostream:38: undefined reference to
`std::_Winit::_Winit()'
nctst.o(.text+0xa49):/opt/intel_cc_80/include/c++/iostream:38: undefined
reference to `std::_Winit::~_Winit()'
nctst.o(.gnu.linkonce.t._ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_+0x2d):
In function `std::basic_ostream<char, std::char_traits<char> >&
std::endl<char, std::char_traits<char> >(std::basic_ostream<char,
std::char_traits<char> >&)':
/opt/intel_cc_80/include/c++/xlocnum:1081: undefined reference to
`std::_Atomic_counter::operator++()'
nctst.o(.gnu.linkonce.t._ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_+0x57):/opt/intel_cc_80/include/c++/xlocnum:1223:
undefined reference to `std::_Atomic_counter::operator--()'
ie lots of 'undefined references'
The full outputs are available in the directory online at http://cloudbase.phy.umist.ac.uk/people/bane/tmp as [compiler]-[machine].out
I am therefore thinking that something (gcc/g++?) isn't quite right on the "work" machine but I'm not really sure where to start looking so your expert advice is most welcome.
As an initial stab, here's what "home" and "work" are like which does show different versions of GNU compilers (and kernel) but I am not convinced this is necessarily the actual problem (ie it's deeper).
"home" (ie the one that compiles it okay) [EMAIL PROTECTED]:~/tmp/netcdf-3_6_0-beta6/src/cxx$ uname -a;gcc --version;g++ --version Linux manchester-campaigns 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux 2.95.4 2.95.4
"work" (ie the one with problems): [EMAIL PROTECTED]:~/tmp$ uname -a;gcc --version;g++ --version Linux ratty 2.4.27-1-386 #1 Fri Sep 3 06:24:46 UTC 2004 i686 GNU/Linux gcc (GCC) 3.3.4 (Debian 1:3.3.4-13) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
g++ (GCC) 3.3.4 (Debian 1:3.3.4-13) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Hi Michael,
I've cc'd this to Brian Mays, who is the netcdf package maintainer according to the control file. Brian, the version of netcdf I am referring to is from Debian/testing, 3.5.0-7.1. Michael is trying to compile netcdf using Intel compilers instead of GNU ones.
Anyway...
I downloaded netcdf and gave it a go. I haven't used icc before apart from compiling mpich, so this was a learning experience for me too :). mpich worked out of the box with icc as both the C and C++ compilers, but I suspect that in mpich there's not much C++ specific stuff.
Firstly, don't use -Vaxlib on the icc command line; Intel have changed a few compiler flags for both icc and ifort to make people rewrite makefiles between versions 8.0 and 8.1.
After much playing around (aka learning), this environment works, with some minor changes to debian/rules.
CC=icc
CXX=icpc
FC=ifort
F90C=ifort
F90FLAGS=-O
FFLAGS=-O
CXXFLAGS=-O -cxxlib-icc
CFLAGS=-O
you probably don't need F90FLAGS, FFLAGS and CFLAGS, but I like them for specifying other optimisations.
Changes to debian/rules:
CFLAGS gets overwritten in debian/rules, so comment it out at the top if you want your own flags. (this is probably not necessary).
CXXFLAGS is also overwritten, which definitely needs changing to get the Intel compiler to work. Change
CXXFLAGS='-fPIC -I ../libsrc $(CFLAGS)' \
to
CXXFLAGS='-fPIC -I ../libsrc $(CXXFLAGS)' \
This is in two places. The debian package maintainer should probably do this and set CXXFLAGS to CFLAGS at the top of the file where CFLAGS gets overwritten. It's then easy to comment out both for non-gcc people.
If you include the Fortran 90 stuff, find the line
gzip -9v debian/tmp-dev/usr/share/man/*/*
and change it to
find debian/tmp-dev/usr/share/man -type f -exec gzip -9v \{} \;
This is needed because one of the Fortran 90 man pages is a symlink, and gzip doesn't like that.
I mucked around using icc instead of icpc as the C++ compiler but couldn't do it; icpc is much easier.
Hope it works :).
Regards,
Daniel.
On Tue, 23 Nov 2004 09:39 pm, you wrote:
I've just seen your web page (http://www.theochem.uwa.edu.au/fortran/intel_on_debian) and was wondering if you could shed any light on the below. I should have added that I am using the l_cc_p_8.1.021 icc package
Thanks, Michael
-------- Original Message -------- Subject: icc C++ problems on Debian 2.4.27-1-686-smp Date: Tue, 23 Nov 2004 13:02:32 +0000 From: michael <[EMAIL PROTECTED]> To: [EMAIL PROTECTED]
Folks - this is essentially a question of how to install Intel compilers on a Debian box, something I would think is solved but...
I've tried debian-users for help but to no avail. I believe this list is more tuned to people using compilers - if not, can you point me in a better direction? And, for the record, I have reported this issue to Intel but am awaiting a reply...
I have just installed 'testing' on my dual Xeon. I downloaded a suitable SMP kernel from backports. Thus I have:
[EMAIL PROTECTED]:~/src/netcdf-3_6_0-beta6/src$ uname -a Linux ratty 2.4.27-1-686-smp #1 SMP Fri Sep 3 06:34:36 UTC 2004 i686 GNU/Linux
I need to use the Intel compilers. (I should add that I've not had any of the below problems when I installed the Intel C/C++ and Fortran compilers on a RedHat box.) I followed Intel's instructions as per their "Platform Notes: Using Intel C++ Compiler on Unsupported Operating Systems". (This was essentially using 'alien' to convert rpm->deb, then dpkg and then sed INSTALLDIR to the name of the actual install directory for all .sh scripts)
Things looked fine. I compiled up 'mpich' and have used.
However, when I tried to compile code yesterday that has C++ headers in (eg "#include <iostream>") it fails to find them.
A simple example (thanks to Kamaraju Kusumanchi on the d-u list):
[EMAIL PROTECTED]:/tmp$ icc sizes.cpp sizes.cpp(1): catastrophic error: could not open source file "iostream" #include <iostream> ^
compilation aborted for sizes.cpp (code 4) [EMAIL PROTECTED]:/tmp$ icc -cxxlib-icc sizes.cpp [EMAIL PROTECTED]:/tmp$ ./a.out 1 4 4 8
(and same behaviour if I replace icc with icpc).
I also note that:
[EMAIL PROTECTED]:~/src/l_cc_p_8.1.021$ /lib/libc.so.6;ls -lt /lib/libc.so.6;ls -lt /lib/libc-2.3.2.so bash: /lib/libc.so.6: Permission denied lrwxrwxrwx 1 root root 13 2004-11-11 18:34 /lib/libc.so.6 -> libc-2.3.2.so -rw-r--r-- 1 root root 1244080 2004-10-13 20:40 /lib/libc-2.3.2.so
And finally, that even when I put the -cxxlib-icc flag with my compilation I still get (more & more severe!) error messages at link time, eg icc -o nctst -g -O2 -Vaxlib nctst.o libnetcdf_c++.a -L../libsrc -lnetcdf icc: Command line warning: ignoring option '-V'; no argument required nctst.o(.text+0x4d): In function `gen(char const*, int)': /opt/intel_cc_80/include/c++/xlocnum:1088: undefined reference to `std::cerr' nctst.o(.text+0x335): In function `gen(char const*, int)': /opt/intel_cc_80/include/c++/ostream:212: undefined reference to `std::cerr' nctst.o(.text+0x44f): In function `dumpatts(NcVar&)': /home/michael/src/netcdf-3_6_0-beta6/src/cxx/nctst.cpp:155: undefined reference to `std::cout' nctst.o(.text+0x491):/home/michael/src/netcdf-3_6_0-beta6/src/cxx/nctst.cpp :157:
undefined reference to `std::cout' nctst.o(.text+0x51d): In function `dump(char const*)': /opt/intel_cc_80/include/c++/xlocnum:1266: undefined reference to `std::cout' nctst.o(.text+0x569):/opt/intel_cc_80/include/c++/xlocnum:908: undefined {snipped}
Help! Thanks, Michael, Atmospheric Physics Group, Univ of Manchester (UK)
------------------------------------------------------------------------ Dr. Daniel Grimwood Chemistry Email : [EMAIL PROTECTED] The University of Western Australia Phone : +61 8 64888563 35 Stirling Highway Fax : +61 8 64881005 Crawley WA 6009
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]