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

Re: icc C++ problems on Debian 2.4.27-1-686-smp



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:
michael@ratty:~/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)
michael@manchester-campaigns:~/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):
michael@ratty:~/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 <linux@networkingnewsletter.org.uk>
To: debian-toolchain@lists.debian.org

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:

m@r:~/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):

m@r:/tmp$ icc sizes.cpp
sizes.cpp(1): catastrophic error: could not open source file "iostream"
 #include <iostream>
                    ^

compilation aborted for sizes.cpp (code 4)
m@r:/tmp$ icc -cxxlib-icc sizes.cpp
m@r:/tmp$ ./a.out
1
4
4
8

(and same behaviour if I replace icc with icpc).

I also note that:

m@r:~/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 : reaper@theochem.uwa.edu.au   The University of Western Australia
Phone : +61 8 64888563               35 Stirling Highway
Fax   : +61 8 64881005               Crawley WA 6009






Reply to: