Support for the Intel C++ compiler is broken

[Roberto Bagnara]

Support for the Intel C++ compiler under GNU/Linux used to work,
starting from libtool 1.5, with version 7.1-x of the compiler.  With
version 8.0-x of Intel C++ things no longer work and upgrading to
libtool 1.5.2 does not help.  To reproduce the problem, I have taken
`cdemo' from libtool 1.5.2 and I have made a minimal set of changes to
make it become a C++ demo.  (The bug is present also in libtool 1.5.6.)
The archive ccdemo.tar.bz2 is attached.
To reproduce the problem, just do the following:

tar jxf ccdemo.tar.bz2
cd ccdemo
autoreconf -i
CC=icc CXX=icpc ./configure
make

This ends with an error when libtool tries to build the shared library.
The command

   /bin/sh ./libtool --mode=link icpc  -g -O2   -o libfoo.la \
     -rpath /usr/local/lib -no-undefined foo.lo -lm

is translated into the (incredibly hairy) command

   icpc -shared /usr/lib/crti.o /opt/intel_cc_80/lib/crtxi.o  .libs/foo.o \
     -L/opt/intel_cc_80/lib -L/usr/lib -limf -lm -lcprts -lcxa -lunwind -lc \
     -lirc /opt/intel_cc_80/lib/crtxn.o /usr/lib/crtn.o  -Wl,-soname \
     -Wl,libfoo.so.0 -o .libs/libfoo.so.0.0.0

which gives the following errors:

/usr/lib/crti.o(.init+0x0): In function `_init':
/usr/src/build/324954-i386/BUILD/glibc-2.3.2-200304020432/build-i386-linux/csu/crti.S:12:
 multiple definition of `_init'
/usr/lib/crti.o(.init+0x0):/usr/src/build/324954-i386/BUILD/glibc-2.3.2-200304020432/build-i386-linux/csu/crti.S:12:
 first defined here
/usr/lib/crti.o(.fini+0x0): In function `_fini':
: multiple definition of `_fini'
/usr/lib/crti.o(.fini+0x0): first defined here
/opt/intel_cc_80/lib/crtxi.o(.data+0x8): multiple definition of `__dso_handle'
/opt/intel_cc_80/lib/crtxi.o(.data+0x8): first defined here

Removing /usr/lib/crti.o solves the problem for `_fini'.  The other
problem is solved by removing /opt/intel_cc_80/lib/crtxi.o since,
apparently this is always included by icpc itself and should not be
repeated in the command line.  Other things in the hairy command seem
to be completely useless: -L/usr/lib, -lunwind, ...

Knowing nothing about libtool's internals, what can I do to help
rectify the situation besides reporting the problem and offering
accounts on a GNU/Linux machine with Intel C++ 8.0-60 installed?
All the best,

     Roberto

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:address@hidden

ccdemo.tar.bz2
Description: BZip2 compressed data