Boost logo

Boost :

Subject: Re: [boost] [regression runner] Preference libstdc++ vs. libc++
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-03-07 11:03:59

On 06/03/2017 22:50, Tom Kent via Boost wrote:

> 1) Convert all compatible clang builds to libc++, don't mess with libstdc++
> & clang.
> 2) Duplicate all the clang builds to build each version with both
> (acknowledging that will add nearly 1/3 to the already large ~125 linux
> runs).
> 3) Change most of the runs, but keep a few token libstdc++ & clang runs,
> with the latest compiler version (what c++ standard c++14? c++1z?).
> 4) Just add a few token libc++ runs, with the latest compiler version (what
> c++ standard c++14? c++1z?).
> 5) Don't add libc++.

A data point no one else seems to have mentioned yet is that while
libstdc++ is pretty much the default STL on Linux, it is increasingly
libc++ which is the default STL on Android. So, longer run, the right
and proper approach would be to test both STLs on Linux assuming that
Android usage of Boost will continue to grow.

Also, I don't know about anyone else, but I use Microsoft's C2 clang
generating the MSVC ABI a LOT. I know it still can't compile all of
Boost without ICEing, but it's getting close and if a regression runner
were available for C2 clang I don't doubt the Microsoft folk would find
that useful.

Finally, LLVM clang targeting the MSVC ABI is also getting close to
viable as a daily compiler on Windows. For me personally, the C2 clang
is much more important because you can run Visual Studio debug sessions
with its output unlike LLVM clang's output which works but is barely
viable. LLVM clang also ICEs when facing Boost with the MSVC ABI, but
it's in totally different places to the C2 clang :)


ned Productions Limited Consulting

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