Boost logo

Boost :

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

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

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
Version: GnuPG v1.4.9 (GNU/Linux)


Boost list run by bdawes at, gregod at, cpdaniel at, john at