Jeff Squyres wrote:
> Ugh. Yes, this is how we determine that you're using the GNU
> compilers or not; I can't believe that icc does that! Lame! :-(
>
> (more specifically, this is how the GNU Autoconf internal test figures
> out whether you are using the GNU compilers or not -- it's not even a
> LAM-specific thing)
They (Intel) do it in order to maintain compatibility with programs
already written for g++ or gcc. They want users to be able to cut over
to icc with only the pain of shelling out money for the compiler (to
improve performance). With options you can tell icc with which version
of g++ it should be compatible, or you can tell it not to define the
GNUC macros. When you think about the market they are competing for, it
makes sense.
> If icc is going to behave badly and pretend to be g++, I don't know
> how we can know that for sure (it's not sufficient to even look at the
> basename of the compiler because -- believe it or not -- I have seen
> sites that do stuff like "ln -s icc gcc", and, even worse, "ln -s gcc
> icc"). :-(
icc defines __INTEL_COMPILER with its version number (currently 800).
You could use this to decide that it's not really g++. I think enough
people use icc that it would be worthwhile supporting, at least to the
same extent as kcc.
> Checking our logic for --with-exflags, I see it works like this:
>
> -----
> if test "$lam_force_exflags" != ""; then
> lam_exflags="$lam_force_exflags"
> -----
>
> And note that "$lam_force_exflags" will be "" if you do
> --with-exflags="". So this is a logic error on our part -- I can fix
> this for 7.1. For 7.1., you should specify --without-exflags, and
> that will pass in no additional exception flags (I'll go commit this
> right now, and update the docs).
I'll look for your 7.1 release.
> Can you send more details on this? It could be an issue with libtool,
> in which case we might not be able to do much -- for better or for
> worse, we have decided that we can only support what libtool
> supports. :-\
This is typical of the build:
gmake[2]: Entering directory `/tmp_mnt/netDISKS/master/netmt/LINUX_X86/rnd/lam/lam-7.0.6/otb/tping'
if icc -DHAVE_CONFIG_H -I. -I. -I../../share/include -I../../share/include -DLAM_BUILDING=1 -O3 -w1 -pthread -MT tping.o -MD -MP -MF ".deps/tping.Tpo" -c -o tping.o tping.c; \
then mv -f ".deps/tping.Tpo" ".deps/tping.Po"; else rm -f ".deps/tping.Tpo"; exit 1; fi
icc: Command line remark: option '-MP' not supported
/bin/sh ../../libtool --mode=link icc -O3 -w1 -pthread -w1 -o tping tping.o ../../share/liblam.la -lutil
mkdir .libs
icc -O3 -w1 -pthread -w1 -o tping tping.o ../../share/.libs/liblam.a -lutil
gmake[2]: Leaving directory `/tmp_mnt/netDISKS/master/netmt/LINUX_X86/rnd/lam/lam-7.0.6/otb/tping'
I found this code in config/depcomp:
case "$depmode" in
gcc3)
## gcc 3 implements dependency tracking that does exactly what
## we want. Yay! Note: for some reason libtool 1.4 doesn't like
## it if -MD -MP comes after the -MF stuff. Hmm.
"$@" -MT "$object" -MD -MP -MF "$tmpdepfile"
stat=$?
if test $stat -eq 0; then :
else
rm -f "$tmpdepfile"
exit $stat
fi
mv "$tmpdepfile" "$depfile"
;;
There is a case for icc later on in this section, so fixing the
detection of icc vs. g++ might help here, too.
--
Dick Hadsell 914-259-6320 Fax: 914-259-6499
Reply-to: hadsell_at_[hidden]
Blue Sky Studios http://www.blueskystudios.com
44 South Broadway, White Plains, NY 10601
|
