The compiler does not support features that are essential for the library.

The toolset is not supported by Boost.Regex.

The test fail with ICE, but the exact reason for ICE is not known. A minimal example of casting any to reference type seem to work. Anyone interested in using this functionality with msvc is suggested to do additional testing.

Compilers need to support partial template specialization to work with zero length arrays.

The test would (most likely) compile and run properly if the workaround syntax .to_container( c ) was applied to all list_of() expressions.

This test could probably be made to work if somebody with knowledge about the compilers would submit a patch.

The test would (most likely) compile and run properly if the workaround syntax .to_container( c ) was applied to all list_of() expressions.

The test could probably be made to work if somebody submitted a patch.

The test would (most likely) compile and run properly if the workaround syntax .to_container( c ) was applied to all list_of() expressions.

The test depends on Boost.Pointer Container which probably does not work for this compiler.

The test does not work for this compiler.

The test depends on Boost.Tuple which probably does not work for this compiler.

This failure is caused by Boost.Function.

This failure is caused by a bug in the compiler triggered by the use of the debug flag '-gall'. It has been reported to the compiler vendor.

This failure is only present in release mode and is caused by /OPT:ICF.

Long double NaN's are apparently handled incorrectly on this platform.

This failure is due to NaNs trapping.

The serialization library does not support this compiler.

XML serialization is not supported on this compiler.

The serialization library does not support this compiler.

XML serialization is not supported on this compiler.

These are strange runtime failures for which there is no obvious explanation. Later versions of the Intel compiler (eg:8.0) seem to have resolved the issue.

For some reason Code Warrior has difficulty compiling some of the input code. This may be related to limitations of locale handling, but it's unclear at this time (2005-May-21).

Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers.

Some compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers.

Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers.

Some compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers.

These compilers are unfortunately able to correctly compile the new format-based input-output code for date time. Suitable, but less flexible, alternatives are available on these compilers.

There is apparently a bug in Borland library such that std::local_time and std::gmtime are returning a time that's 1 hour ahead GetSystemTimeAsFileTime during DST. This is a rather serious problem in that some of the date-time clock interfaces will give the wrong current time.

The sun 5.8 compiler and standard library have a problem with the classic facet which causes some of the io tests for date-time to fail. Overall this should not affect most uses of the library.

The STLPort standard library has issues with some custom facet settings causing an unexplained failure in these facet tests.

The STLPort standard library has issues with the handling of the classic facet which causes some fo the i/o tests for date-time to fail. Overall this should not affect most uses of the library.

MSVC 7.1 with its standard library passes all date-time tests. For some reason when paired with stlport a few widestream io tests do not format output correctly. Overall this should not affect most uses of the library.

Although these tests compile, the execution aborts for an unknown reason. Note that sometimes the excution is ok on cw-9_4. This may be fixable if someone can track down the source of the problem.

These tests are failing with the beta2 version of VC_8. At least one of them is directly a result of the new VC_8 standard library restricting the year value in a tm struct to be positive (that is greater than year 1900). This is a change from VC7_1 and Microsoft is considering removing this restriction.

These tests are for serialization which has been marked as unusable. The issue was specifically noted on AIX version : 5.2.0.41 using IBM XL Version 8.0.0.0.

The failure is caused by a standard library bug. It doesn't support user defined facets which are not default constructible. This has been reported to the compiler vendor.

These tests rely on the ability of an std::map to be instantiated on an incomplete type. The Rogue Wave version 2.2 and higher does not allow this.

The failure is caused by a standard library bug. It doesn't support user defined facets which are not default constructible. This has been reported to the compiler vendor.

The failure is caused by a standard library bug. The end-of-stream istream iterator can only be constructed when the istream iterator has been instantiated with char as the character type. This has been reported to the compiler vendor.

The exact reason of this (linker related) bug is unresearched. The test passes on some environments. The test was found to fail on a platform whit a german version of the compiler.

Due to standard library bugs this configuration is not supported by the most recent version of the library.

Due to standard library bugs, this version is not supported. More recent version of the library should work OK.

fstream for this compiler has serious problems and is not supported

The library does not support wide paths on this compiler because it does not support SFINAE.

These failures are reported to be fixed in Sun's next compiler release.

This compiler does not support the Boost.Range library, on which Boost.Foreach depends.

This compiler does not support detection of const rvalues.

This compiler does not support detection of rvalues.

These compilers cannot handle BOOST_FOREACH in a template, where the collection type depends on a template parameter.

This failure is because the Boost.Range extension mechanism is broken on these compilers. It requires ADL which these compilers do not support.

is_base_and_derived<> is broken on this compiler, but the problem can be worked around by specializing boost::foreach::is_noncopyable<> for collection types that are noncopyable.

The failure is caused by a standard library bug: the iostream components fail to handle ios::internal flag.

hash_value is not overloaded for arrays for older versions of Visual C++. There is a work around so that boost::hash<T[N]>, boost::hash_combine and boost::hash_range work.

On this compiler the hash function is returning the same value for std::numeric_limits<long double>::max(), std::numeric_limits<long double>::max() / 2 and std::numeric_limits<long double>::max() * 3 / 4. This suggests the hash function isn't taking into account the full range of long double - it might be converting it to a double. This won't cause anything to break, but means that the hash function isn't as good as it should be for long doubles.

On this platform both std::frexp and std::ldexp treat long doubles as longs, so the hashing algorithm does the same. This means that you'll get very bad results for long doubles that can't be represented by doubles.

These examples only work on compilers with support for ADL. It is possible to work around this, but I wanted to keep the example code as clean as possible.

It appears that Borland doesn't find friend functions defined in a class by ADL. This is easily fixed but this example is meant to show the typical way of customising boost::hash, not the portable way.

The test demonstrates a Borland bug - functions that aren't in a namespace don't appear to be found by ADL.

This failure is due to a problem with partial ordering of class template partial specializations.

The test fails due to compile error in relaxed_heap.hpp. The compile error is likely caused by a compiler bug.

The test fails from completely unknown reason -- it might be compiler bug, or compiler misconfiguration or testing system bug.

This is gcc bug 26526, and is fixed in later releases.

compiler can't compile "windows.h" in strict mode

The failure reflects a problem with the build system: the zlib object files are generated in the wrong directory.

I'm not sure whether CodeWarrior is correct to report that the member in question is inaccessible; however, when the member is made public an internal error occur that I have not been able to fix, so for now the question is moot.

Memory mapped files are not supported in QNX Neutrino version 6.3.0.

Fails to compile on some installations but not others; may depend on which compiler updates have been installed

These six tests pass individually but cause a compiler stack overflow when compiled as a group

No bzip2 support on the testing machine and no way to disable this test with BBv2 at present.

The test fails at runtime for unknown reasons.

The compiler is not supported by the library due to an utterly broken templates support.

This failure is caused by a deficient SFINAE implementation; the bug was fixed in the next major compiler version (CodeWarrior 9.x).

This failure is caused by a deficient SFINAE implementation.

This failure is caused by a problem with recursive templates and default template parameters, fixed in Update 2.

This failure is caused by a lack of compiler support for template template parameters.

This is an advanced functionality that hasn't been ported to the deficient compilers (yet). Patches are welcome!

This is a regression in the gcc 4.1 series that will be fixed in gcc 4.1.2. See bug #28088 for details.

This is reported to be fixed in the next Sun compiler release.

When compiling this test, aCC6 runs out of memory. The HP compiler group is aware of this issue and is working on the fix.

This library has never worked [on Borland 5.5.1 and 5.6.4], and the only tests that 'pass' are compile-fail tests failing for the wrong reasons!

Known error in MSVC. see http://boost-consulting.com/boost/libs/multi_index/doc/compiler_specifics.html#msvc_60 for more information.

The VC++ 6.0 backend runs out of internal resources while trying to process the Comeau output for this library; Comeau Computing has been asked about a solution. On the other hand, Comeau 4.3.3 with VC++ 7.0 backend works fine.

This error shows when using the dynamic version of the STLport library. The problem is reportedly fixed in STLport 5.0 (in beta stage as of this writing.)

Boost.Serialization is not supported on this platform.

This test fails due to limitations of the template instantiation model used in the testing environment (-timplicit_local) resulting in erroneous duplication of some function-static variables. The test passes with other template instantiation models.

The test is exposing the following known error of Sun Studio 11: overload resolution fails if a) some class has a conversion operator to a reference to a built-in type, and b) overload resolution involves a user-defined operator as well as a built-in operator, and c) the built-in operator takes the result of the conversion mentioned in a) as an operand. A fix will be reportedly included in patch no 6 of Sun Studio 11.

This error shows when the code has become too complex for the compiler to handle. The problem has no relationship with the functionality being tested, which in fact does work for MSVC++ 7.0.

msvc 6 compiler failure. The facility being tested conflicts the the compiler in a fundamental way and cannnot be worked around.

This failure appears when STLPort is built and used as a DLL with msvc 6. STLPort suggests that the next version of STLPort(5.0) will include a workaround for this problem.

The library is believed to work in this configuration if compiled against Spirit 1.6. The latter is not provided by the particular testing environment these tests have been run in.

All tests that serialize derived pointers currently fail with Metrowerks compilers.

This is caused by a compiler bug in this particular version, but not present in version thereafter. The compiler has some difficulties resolving operators to methods in the archive classes. This can be worked around by calling the operator directly, and such a work around is already present in library code. This test demonstrates that this can happen in user code.

The CW compilers have problems with the static construction idiom used to implement the type registration in the Boost.Serialization library. In many cases CW specific work arounds are implemented in the library but this one is not immediately solvable. There is a user work around possible, please contact the library developers on the Boost list for information on the work around if needed.

The variant library is not supported for this compiler version. Therefore serialization of variants doesn't work.

The compiler fails with an error supposedly related to std::fpos<>::_Stz from the <iosfwd> header. It is not known what causes the compiler to instantiate this field and what causes the instantiation to fail.

This failure is caused by an unresearched compiler bug; the conditions under which the bug manifests itself seem to be uncommon, however, and the static version of this same test builds and runs correctly.

Historically, Spirit supported a lot of compilers, including (to some extent) poorly conforming compilers such as VC6. Spirit v1.6.x will be the last release that will support older poorly conforming compilers. Starting from Spirit v1.8.0, ill conforming compilers will not be supported. If you are still using one of these older compilers, you can still use Spirit v1.6.x.

The reason why Spirit v1.6.x worked on old non-conforming compilers is that the authors laboriously took the trouble of searching for workarounds to make these compilers happy. The process takes a lot of time and energy, especially when one encounters the dreaded ICE or "Internal Compiler Error". Sometimes searching for a single workaround takes days or even weeks. Sometimes, there are no known workarounds. This stifles progress a lot. And, as the library gets more progressive and takes on more advanced C++ techniques, the difficulty is escalated to even new heights.

Spirit v1.6.x will still be supported. Maintenance and bug fixes will still be applied. There will still be active development for the back- porting of new features introduced in Spirit v1.8.0 (and Spirit 1.9.0) to lesser able compilers; hopefully, fueled by contributions from the community. For instance, there is already a working AST tree back-port for VC6 and VC7 by Peder Holt.

This failure is caused by a compiler bug that manifests itself in the particular environment/hardware configuration the test has been run in. You may or may not experience this issue in your local setup.

This compiler is not supported.

Native mode is not supported for this compiler.

Emulation mode is not supported for this compiler.

The feature is not supported by this compiler.

This failure is caused by a compiler bug. Templated operators that combine different iterators built with iterator_facade or iterator_adaptor may be present in an overload set even when those iterators are not interoperable. The usual result is that error messages generated by illegal use of these operators will be of lower quality.

This failure is caused by a compiler bug. is_convertible<T,U>::value may be true for unrelated iterators T and U (including many of the Boost specialized adaptors) which use enable_if_convertible to restrict the applicability of converting constructors, even when T is not convertible to U because instantiating the conversion will cause a compilation failure.

This failure is caused by a compiler bug. The compiler tends to drop const-ness and as a result some indirect_iterators will have pointer and reference members of T* and T& that should have been T const* and T const&.

This test fails with a link error that is most likely a STLport issue. As STLport 4 is officially unsupported there is no known resolution.

For some currently unknown reason, with aCC6, this test can be compiled only in strict ansi mode. Since on HP-UX/aCC6 boost testing is done in the default compilation mode, this test fails to compile on this platform.

There appears to be a bug in gcc's

std::exp (long
              double)

on this platform.

std::numeric_limits>long double<::infinity() is apparently broken in this compiler: it's filed as bug 6347520 with Sun.

Not yet diagnosed the precise reason these tests give bad results.

std::numeric_limits>long double<::infinity() is apparently broken in this compiler.

Incomplete std::complex support make these tests pointless (the complex trig functions are absent).

These have yet to fully investigated, but the code is known to compile with more conforming compilers, probably workarounds are possible if someone is prepared to invest the time.

This compiler is not sufficiently conforming to compile these tests.

Appears to be a bug in STLport's complex abs function, but needs more investigation.

This appears to be a problem with STLPort's abs function: the issue only effects the test code. A workaround should be possible but users should be encouraged to use STLport 5 instead.

No true long double standard lib support causes these tests to fail.

This is Intel issue 409291, it should be fixed from compiler package l_cc_c_9.1.046 onwards.

This failure appears to be caused by a compiler bug: please note that the issue only effects the test suite, not the library itself. A workaround is available but breaks other compilers.

This test ensures the inclusion property of interval arithmetic is available for built-in floating-point types float and double. If the test fails, interval<float> and interval<double> should not be used on this compiler/platform since there will be no numerical guarantee.

This compiler has some problems with name looup / overload resolution.

This failure is unresearched. Presumably, the problem is that the abs function is not available in the "right" namespace with this compiler/stdlib combination.

This old version of the stlport library causes the BOOST_NO_STDC_NAMESPACE macro to be set. But this conflicts with the requirements of the library.

The failure is caused by standard library deficiencies -- it lacks the basic_string class template and the <locale> header.

The failures are caused by problems with std::locale implementation

The failures are caused by compiler bug: it's not possible to explicitly pass template arguments to member template function. The failure is serious and makes one of the primary interfaces unusable.

Several compiler bugs were worked around in order to get this test to pass, so it could be considered to be only partially working. However, the library's macro system, which is really being tested here, does work on this compiler, which is why we worked around the failures. Please see the test's source file for details.

These compilers do not support SFINAE, so are expected to fail this test.

Borland does not support this feature. A compatibility syntax might be developed later on.

This feature generally requires advanced compiler features not supported by these compilers. It might be possible to work around the issue on VC6/7, but at this time no such workaround has been done.

This is old and should not be tested any more.

These test failure are reported to be under investigation at Sun's compiler labs.

The error is due to problems in the standard library implementation. It should be fixed in newer versions of the compiler.

This error seems to be a bug the compiler. Please submit a patch.

This error seems to be a bug the standard library. Please submit a patch.

This test fails because the test ptr_vector fails. Please see the note for that test.

For sun the problem is that insert(iterator,range) is not available due to partial ordering errors (the core library remains usable). For codewarrior the problem is at least std::auto_ptr overloads (the core library remains usable).

For hp, this compiler bug is insignificant. For sun the problem is that transfer(range,ptr_map) is not available due to partial ordering errors (the core library remains usable). For codewarrior the problem is not known so please submit a patch.

For sun the problem is that transfer(range,ptr_map) and insert(range)code> is not available due to partial ordering errors (the core library remains usable). For codewarrior the problem is at least std::auto_ptr overloads (the core library remains usable)..

This cause of this problem is unknown. Please submit a patch.

For sun the problem is due to Boost.Test.

Seem like a bug in the compiler. Please submit a patch.

The library fails to compile because of an error in the C++ standard library implementation on this platform. It incorrectly assumes that fpos_t is of an integral type, which is not always the case. This is fixed in a later release.

This compiler seems to be having trouble digesting Boost.Tuple. Until it can handle Boost.Tuple there's little chance it will handle Boost.Python

The problems with GCC 2.x only occur when C++ exceptions are thrown and the framework catches them, which happens quite often in the tests. So technically GCC 2.x is usable if you're careful.

The tests are failing because the libraries being built are targeted to use the cygwin.dll, while the tests are run against a python executable that depends on msvcrt.dll. This combination cannot be expected to work. (The tests will pass if the additional compiler switch -mno-cygwin is used during compile and link.)

This test assumes standard-compliant dependent template name lookup which is performed by aCC6 only in strict ansi mode. Since on HP-UX/aCC6 boost testing is done in the default compilation mode, this test fails to compile on this platform (in strict ansi mode, it compiles and succeeds).

Reported to Intel as issue 409291, and confirmed as a problem. Probably this relates to a specific Linux-Kernal or GLibC version.

Test fails with ranlux*_O1 RNGs when saving and recalling the state due to a bug in the double to string conversion. The problem has been reported to QNX as PR29252.

This test fails because of limitations in the system assembler version used by GCC. It most probably would pass if the test were split into multiple source files.

For most compilers this is due to problems with built-in arrays (notably char arrays) and operator==() and operator!=() for iterator_range. Thus, not using built-in arrays fixes the problem. For other compilers it is simply a bug in the standard library.

This test probably fails because it uses built-in arrays. So do expect these functions to work in normal code.

The string functionality is expected to work if the user employs std::string and stays away from built-in arrays.

For most compilers this is due to problems with built-in arrays (notably char arrays) and operator==() and operator!=() for iterator_range. Thus, not using built-in arrays fixes the problem.

At the time of release I couldn't figure out why this was failing. Anyway, the failure is not very important; also, the well-definedness of "singularity" of an iterator range is likely to change.

The test requires support for Argument Dependent Lookup (ADL) which the compiler in question does not provide.

No Wide character support on this platform.

This test requires features that are unsupported by Como: use and building of dll's mainly.

GCC on tru64 appears not to cope with C++ exceptions thrown from within threads.

This test fails because a dependency (Boost.Program Options) doesn't build with this compiler.

There appears to be a linker bug that prevents these projects from building, see http://qc.borland.com/wc/qcmain.aspx?d=32020.

Test fails due to unresilved externals from STLport: appears to be an STLport bug.

These tests pass when run directly from the command line, but fail when run under the regression test script. The issue has never been fully pinned down, but appears to be related to how long the tests take to run.

A runtime failure of this test indicates that this platform dynamically links code in a manner such that under certain circumstances more than one instance of a header-defined static class member can exist at runtime. See here for more information.

A runtime failure of this test indicates that this platform statically links code in a manner such that under certain circumstances more than one instance of a header-defined static class member can exist at runtime. See here for more information.

This test runs without problem on Borland compilers, which means the static assertion is not being caught.

The test verifies that Boost.Test detects division by zero. Division by zero has an undefined result on PowerPC processors. The compiler has to emit extra code to assert that the divisor isn't zero. Compiler options -fno-trapping-math and -fnon-call-exceptions might affect this. However, in default configuration no check is done, and division by zero is not detected.

The test appears to test that failed assertion result in non-zero exit status. That seems to be not the case, for unknown reasons.

This failure is caused by a conflict between the compiler and the testing environment: the tests are run on a platform with too recent version of glibc, which is not currently supported by the compiler vendor (Intel). If you are having the same problem and really want to make things work, renaming strol symbol in the compiler's static runtime library (libcprts.a) to something else is known to resolve the issue.

When a thread ends, tss data needs to be cleaned up. This process is mostly automatic. When threads are launched by the Boost.Thread API cleanup is handled by the library implementation. For threads, launched by the native operating system API it is not possible to get this cleanup on every compiler/platform. A warning (error) will be present in this case, which cleary states this fact. It is recommended to start threads only by means of the Boost.Thread API if you need to avoid the leaks that appear on the end of the thread. If this is not possible the cleanup can be invoked from user code before the process actually ends. For library implementors this means to call these functions during library initialization and finalization.

This failure is caused by the lack of compiler support for class template partial specialization. A limited subset of the tested functionality is available on the compiler through a user-side workaround (see http://www.boost.org/libs/type_traits/index.html#transformations for details).

This functionality is available only on compilers that implement C++ Core Language Defect Report 337.

The Type Traits library is broken when used with Sunpro-5.3 and the argument to the template is an array or function type. Most other argument types do work as expected: in other words the functionality is limited with this compiler, but not so much as to render the library unuseable.

The Type Traits library is broken when used with Sunpro-5.8 and the argument to the template is a function type. Most other argument types do work as expected: in other words the functionality is limited with this compiler, but not so much as to render the library unuseable.

Older versions of MWCW incorrectly align pointers to member functions (they use 12-byte boundaries, rather than a power-of-2 boundary), leading to alignment_of / aligned_storage to fail with these types on this compiler.

VC6/7 has a buggy using declaration syntax which basically makes it impossible to implement the namespace forwarding that this library relies upon. See KB article 263630 here: http://support.microsoft.com/default.aspx?scid=kb;en-us;263630

Metrowerks Codeworrier has partial TR1 support built in which conflicts with this implementation. Porting to this compiler is almost certainly possible, but will require some work by someone who has this compiler.

These tests test features that are not supported in the current Boost implementations of TR1 components, they will currently fail on all compilers, unless that compiler has native TR1 support.

These tests fail on this platform due to a lack of wide character support.

These tests fail on this platform due to incomplete wide character support.

Support for Borland C++ in the various TR1 libraries is pretty poor (due to numerous compiler bugs sadly). The TR1 concept checks are *very* strict, and are expected to fail with this compiler. In addition most of the type_traits tests fail whenever debugging support is turned on with an internal compiler error. More conservative uses are more likely to succeed with this compiler however.

These tests fail on this platform due to a recuring GCC bug.

These tests fail due to a known compiler bug that is fixed in more recent GNU compiler releases. Users are very unlikely to encounter this as a real problem in practice.

These tests fail due to a known compiler bug that is fixed in more recent releases. Users are very unlikely to encounter this as a real problem in practice.

These tests fail due to a known compiler bug that is fixed in more recent releases. This functionality may not be usable with this compiler.

These tests fail due to a known stdlib bug that has been reported to the vendor.

This functionality is available only on compilers that implement C++ Core Language Defect Report 337.

These failures appear to represent a genuine issue with the Boost.Random library that has yet to be addressed.

These failures are completely spurious: they're caused by the tests being run with bjam -j2 and the post-processing not coping with the resulting output. These failures should clear if these tests are re-run at some point in the future.

This library is almost unusable with VC7 due to name lookup issues.

Compiler has a problem with BOOST_STATIC_CONSTANT in nested templates inside class template specializations.

This failure is caused by a compiler bug (default-constructed scalar types are not zero-initialized) that has been fixed in the latest versions of the compiler (VC 7.1 and greater).

The test takes more that 30 minutes to compile and the compilation is automatically killed. It is likely caused by the compiler bug, but it unknown how much this bug affects regular use of the operators library. Is it also unknown if the test can be refactored so that not to trigger this bug.

This toolset isn't supported because of the used Spirit V1.8.x, which in turn is not usable with this toolset.

These compilers do not support class template partial specialization.

Boost.Fusion doesn't work on this compiler.

This compiler doesn't support SFINAE / enable_if

Digital Mars cannot seem to handle dependent default template parameters, such as "template < class T, bool B = is_foo < T > ::value >"

This test fails only intermittently. The failure is caused by a problem in Boost code. The Boost developers are aware of the problem and plan to fix it. The failure is caused by a compiler bug. The failure is caused by a compiler bug, which has been reported to the compiler supplier (or is already known to them). The failure is caused by a standard library bug. The failure is caused by a standard library bug, which has been reported to the standard library supplier (or is already known to them). The failure is probably caused by the test code, harness, or configuration. Thus, it may not affect users of the library. The failure is serious and likely to prevent all use of this Boost library with this compiler. The failure is serious and likely to prevent all use of this Boost library with this compiler. The failure is caused by a compiler bug, which has been reported to the compiler supplier (or is already known to them). The failure is caused by a platform API bug. The failure is caused by a platform API bug, which has been reported to the platform API supplier (or is already known to them). The failure is not serious and will not affect most users. The library degrades gracefully. This compiler's bugs are not supported by the library. Locales missing or adequately supported by this compiler. Missing or inadequate wchar/wstring/wstream support for this compiler. No std iterator traits for this compiler. Library has limited input/output support due to compiler inadequacies. No high precision clock for this platform. A bug in standard library prevents passing std::set from DLL to application. A fixed <tree> header is available from http://www.dinkumware.com/vc_fixes.html. Although the documentation from the Comeau website would make it appear that windows DLL's are supported using the --windows option, after some experimentation we have been unsuccessful in making dll configurations work correctly. The failure is caused by a runtime limitation. Locale support is only available with the static linked variant of the runtime. Generally the dynamic linked variant is required when building dynamic modules, DLL, so, etc. This failure is caused by a compiler bug with no known workaround. Patches are welcome! This failure is caused by bugs in the standard library implementation and/or bugs in the compiler. Unresearched failure -- please contact library developers for more information about possible causes. The test fails due to unresearched issues. The library developers are aware of this failure, but need help with investigating/addressing it for future releases. The support for this deficient compiler will be dropped starting from Boost 1.33.0 release. Please use one of the previous Boost releases if you need the library to work on this compiler. This failure is caused by compiler bugs or limitations. Some advanced or esoteric library features may be unavailable or only partially available. This does not impact most common uses of the library. This failure is caused by a compiler bug. Certain code constructs that should fail compilation are accepted by the compiler. This can mask some programming errors, but does not impact the usability of the library. The failures are caused by the wrong handling of the std::internal flag in the iostreams implementation of the standard library used on that compiler/platform combo. Apart from that, the format library works as expected. The failures are caused by the fact that the iword and pword arrays seem to share the same memory area in the iostreams implementation of the standard library used on that compiler/platform combo. As long as you stay clear of iword and pword, the library should work ok. This failure occurs only when using shared libraries for this compiler and platform, although the same programs should work properly when using static libraries. This problem has not been researched. Wide character support is disabled in the GNU Standard C++ library as supplied on the QNX Neutrino version 6.3.0 distribution. This problem is due to the non-conforming STLport implementation of vector's swap: it can be easily reproduced with the following code snippet: typedef std::vector<int> vector_type; typedef vector_type::reference reference_type; vector_type v1(4u, 1); vector_type v2(7u, 0); reference_type ref = v1[2]; int x = ref; std::swap(v1, v2); BOOST_CHECK(v2[2] == x); // ok v2[2] = 1 - v2[2]; BOOST_CHECK(ref != x); // oops