[boost] Issues with intel's compiler and newer builds of GCC

Subject: [boost] Issues with intel's compiler and newer builds of GCC
From: Bryce Lelbach (admin_at_[hidden])
Date: 2010-10-20 00:44:39

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While working on getting icc to not choke on Serialization (the Boost test boxes
indicated that icc was failing to build with the addition of my changes), I came
across a very nasty bug the occurs when using icc with version 4.5 or higher of
GNU's standard library - GNU's <iomanip> uses what are either illegal or C++0x
semantics which icc doesn't support. Serialization uses <iomanip>, and icc seems
to select the latest version of libstd++ installed on a Linux machine as it's
default standard library (I have been unable to find an Intel standard library -
I'm assuming such a thing doesn't exist).

When using an older version of libstd++, icc + Serialization compiled fine. I
removed all uses of IO parameterized manipulators in Serialization (there were
only maybe half a dozen cases)*, and got icc to compile Serialization with
libstd++ v4.5.

Is there any chance the linux/darwin Intel build bots can be set up to use libstd++ 
v4.4, if they're not already using it? Intel is apparently aware of this issue,
but it won't be fixed until their next major release
(http://software.intel.com/en-us/forums/showthread.php?t=74691).

If the build bots aren't using v4.5 of GNU's standard library, then I'm at a loss
as to why Serialization is failing to build on them. My only other thought is that
the timeout for the build cycle is too low - the failures indicate that the error
is a timeout after 300 seconds.

On a more general note, is Intel on Linux/Darwin a "supported" Boost compiler? Unless
I've missed something, Intel doesn't provide a standard library, and I find it a
bit troubling that they ship their compiler to use GNU's standard library by default.
Intel is far behind GCC in C++0x support, and newer versions of the GNU standard
library have been making increasing use of GCC's C++0x support. Unless icc starts
shipping with an older version of libstd++/use a compiler neutral standard library
such as the Apache standard library/starts to catch up with GCC's C++0x support,
I imagine that using icc to compile C++ code that makes use of the standard library
will become increasing difficult.

* I also had to modify proto/debug.hpp to not use <iomanip>. Eric, when I was
  having an issue with typeinfo in proto/debug.hpp a couple days ago, you mentioned
  that proto/debug.hpp shouldn't be included by proto/proto.hpp? If that's accurate,
  is there any chance that change could be made, and if not, can I commit my
  changes to proto/debug.hpp or send them to you as a patch for review?

- -- 
Bryce Lelbach aka wash
http://groups.google.com/group/ariel_devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAky+c7cACgkQO/fqqIuE2t4DZQCfUnhGAsqX4GDZu3Ze7BvrPBRL
XRkAn33vWcTm1RuXk2iuQWH0+bp+RVUf
=mHwK
-----END PGP SIGNATURE-----