On Wed, 2 Jun 2004, Richard Hadsell 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! :-(
>
> 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.
I think I would be more sympathetic to Intel if they did this *and*
actually provided full gcc compatability. By saying that they are one
compiler and then don't provide full support for everything that that
compiler supports (including the command line compiler/linker flags), they
force other packages to have to figure out that it *isn't* the GNU
compiler suite, and then provide workarounds. Grumble.
But I digress...
The issue is that it is not LAM's test that determines that we're using
GCC -- it's a GNU Autoconf/Automake-provided test (I have to admit that
this is one of the fuzzy areas that I'm not sure which one is making the
determination). LAM/MPI 7.0.6 uses the following versions:
Autoconf: 2.59
Automake: 1.8
Libtool: 1.5
A little insight into the LAM/MPI release process...
Autoconf 2.59 is the most recent; Automake 1.8 and Libtool 1.5 are not the
latest, but we elected not to use the latest because they didn't seem to
be fully stable -- 7.0.6 was a quick bug-fix release so we just used the
same versions as in 7.0.5. I believe that we mostly used that logic /
rationalization for most of the 7.0.x series -- there have been releases
of Autoconf/Automake/Libtool with serious flaws, so we only upgrade when
we can do full regression testing on a wide variety of platforms and
compilers, which we really didn't want to do for 7.0.6.
>> 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
> [snipped]
> I found this code in config/depcomp:
Ah -- this looks to be a similar consequence of determining that we are
using gcc instead of icc. I'm pretty sure that this one is Automake
determining to use gcc instead of icc (depcomp is an Automake helper
script).
Tell you what -- I'll make a 7.0.7b1 tarball with the latest Automake /
Libtool and let's see if that fixes the problems. It's quite possible
that Intel contacted the maintainers of those packages and worked out a
plan to do the Right Things.
http://www.lam-mpi.org/~jsquyres/lam/beta/lam-7.0.7b1.tar.gz
http://www.lam-mpi.org/~jsquyres/lam/beta/lam-7.0.7b1.tar.bz2
MD5 sums:
37a3fe396d2c7ade6cb0db8ba30dd6b2 lam-7.0.7b1.tar.bz2
2b3f40aab3b56cb12da3ac8406722b52 lam-7.0.7b1.tar.gz
SHA1 sums:
b7ee485cac4e4056b3485e90676a4637c620fb14 lam-7.0.7b1.tar.bz2
f6e88642304acf4fd65250237037df90a07f1013 lam-7.0.7b1.tar.gz
==> Note to those of you surfing in here from the web archives: I make
no guarantees about how long this URL will be valid.
Can you test this tarball and let me know if it works without problems?
(I waited to send out this post until the 7.0.7b1 tarball was ready; in
the meantime, Ralf Wildenhues posted that at least some of these issues
have been fixed in the newer Automake releases -- so it looks like this
was the right decision. Woo hoo! :-) )
--
{+} Jeff Squyres
{+} jsquyres_at_[hidden]
{+} http://www.lam-mpi.org/
|
