Greetings, I’m trying CC-ing all the folks I could think of that are likely running bots for Clang. If I’ve missed any, sorry, please add them.
As you may have heard on various lists, it’s time to switch Clang (and LLVM) to use C++11. The first step is establishing a new baseline of compiler versions that are supported:
If you are helping to keep our build bot infrastructure running and up-to-date, please check the host compiler versions and reply here if you’re going to have trouble upgrading. My rough plan based on chatting with some folks is to submit checks to cmake and configure on Monday to produce an error on older toolchains without some flag to force old toolchain support.
So reply to this thread if you need more time, or if all your bots are ready-to-go! Thanks a bunch!
: Most of these compilers were available in the middle (June) of 2012, and based on the planned 3.5 release time frame of the middle of 2014, that will mean a roughly two year spread of compiler releases. MSVC 2012 was later, but the community seems comfortable with requiring the upgrade. Also, these versions include very significant improvements that make adopting C++11 features much more viable. This was discussed at some length on the mailing list previously, and I’m not really trying to re-open debate here, just reminding folks. =]
I believe I’ve upgraded the lab hpproliant1 machine (http://lab.llvm.org:8011/buildslaves/hpproliant1) running the GDB 7.5 test load on Linux, to GCC 4.7 - we’ll see how that bot cycles.
The other bot I have some ownership over is labmini1 (http://lab.llvm.org:8011/buildslaves/lab-mini-01) which runs the ye olde GDB test suite on Mac. That machine still seems to have the classic Apple GCC 4.2 as ‘gcc’ and Clang 3.2 as ‘clang’. I don’t know which compiler’s in use there - are our build scripts smart enough to choose clang by default on mac? If not, I’ll need to do something there, though I’m not sure what the right answer is. (in terms of installing new software (modern GCC on Mac? Blasphemy!) or changing the machine configuration (aliasing gcc to clang) or the buildbot config (passing flags to configure, etc, to use clang explicitly))
"firstname.lastname@example.org" <email@example.com> writes:
The other bot I have some ownership over is labmini1 (http://lab.llvm.org:8011
/buildslaves/lab-mini-01) which runs the ye olde GDB test suite on Mac. That
machine still seems to have the classic Apple GCC 4.2 as 'gcc' and Clang 3.2
as 'clang'. I don't know which compiler's in use there - are our build scripts
smart enough to choose clang by default on mac?
The configure logs from that machine's runs indicate that it cleverly
chooses clang to compile with
from http://lab.llvm.org:8011/builders/clang-x86_64-darwin12-nt-O3/builds/2354/steps/configure/logs/stdio :
Greetings, I'm trying CC-ing all the folks I could think of that are
likely running bots for Clang. If I've missed any, sorry, please add them.
As you may have heard on various lists, it's time to switch Clang (and
LLVM) to use C++11. The first step is establishing a new baseline of
compiler versions that are supported:
Does this mean clang with require libstdc++4.7 too? Or can gcc 4.7 target
libstdc++ 4.6 somehow?
Is libc++ going to be a requirement on OS X (i.e. clang 3.5+ won't run on
OS X versions older than 10.7), or will using the newest libstdc++
available on OS X (4.2) be ok too?
Also, when you say "Clang 3.1", how does that relate to an Xcode-provide clang version? The table here:
<Xcode - Wikipedia;
states that Xcode 4.3 (May 2012) through 4.5.2 (Nov 2012) are all "based on LLVM 3.1svn". Will they all be supported? I hope at least 4.3.3 will be supported, as it was the last with the 10.6 SDK.
I am sure http://bb.pgr.jp/ has been C++11 ready.
- gcc-4.4 and msc16 were dropped.
- Linux builders use gcc-4.7.2 (SL based homebrew)
- Introduced mingw-w64-gcc-4.8.1 (for now targeting x64)
- All CMake builders are configured with LLVM_ENABLE_CXX11=ON.
- configure will run as-is. expected to follow default option.
a few new builders will come. Working in progress.
Yes. Part of the reason to pick GCC 4.7 is because its standard C++ library
has a reasonably well tested and correct implementation of a large amount
of the C++11 standard library. The standard library improvements wil lbe
among the most dramatic as those have been widely implemented for longer in
This one is less clear. Practically, the answer may be yes. But I don't see
any fundamental reason why libstdc++4.7 wouldn't work if compiled and
installed on OS X. Similarly for GCC 4.7. I just don't think that that is a
widespread configuration so I suspect it will be less tested on the build
So clang will stop running on regular Ubuntu Precise?
Yes. Note that the next LTS is scheduled to be out before the 3.5 release,
so it only people working against trunk and hosted on LTS that will have a
window where they need to install a more recent host compiler.
It's not just a host compiler, you also need to deploy the newer libstdc++
to all machines where you want to run clang, right?
(If so, this means we won't be able to update clang in Chromium land on
linux for the foreseeable future. Which shouldn't hold the llvm project
back of course, if you think it's reasonable to assume that everyone will
upgrade to the new LTS as soon as it's out. I think this is an optimistic
(Update: We'll try bundling libstdc++4.7 with our clang binaries somehow,
and are hopeful that we can keep things working for us.)
FYI, this is happening now-ish.
Chandler, as of this morning ToT builds fine when I point CC and CXX to the
Clang 3.4 release binaries. However, it's unlikely that Clang 3.4 picks up
libstdc++4.7, because I did not install it.
Are you going to force the libstdc++ version too in the configure/cmake
checks at some point?