The following minimum compiler versions are strongly recommended.
Clang 3.5 and above
GCC 4.7 and above.
Anything older may work.
We’re having more and more trouble supporting pre-4.7 versions of gcc, especially in C++03 mode.
Much of the early gcc support was driven by the fact that Apple was never going to move past gcc 4.2.1, and the necessity of supporting that compiler - but that ship has sailed.
I’d like to officially drop support for those compilers.
In general, I’d be happy requiring a compiler that has full C++11 support for building a C++11 standard library - doing otherwise seems odd. My one concern (which I don’t think applies in this specific case) is on the dependency between libc++ and clang. We need to make sure that there’s an upgrade path that lets us bootstrap libc++ with an older clang, before building a newer one.
The following minimum compiler versions are strongly recommended.
Clang 3.5 and above
GCC 4.7 and above.
Anything older may work.
We’re having more and more trouble supporting pre-4.7 versions of gcc, especially in C++03 mode.
Much of the early gcc support was driven by the fact that Apple was never going to move past gcc 4.2.1,
and the necessity of supporting that compiler - but that ship has sailed.
I’d like to officially drop support for those compilers.
I am a mere user of libc++, so this may be a non-problem, but I feel the need to check.
I make extensive use of backwards compatibility on OS X: building on, say, OS X 10.11, and aiming to have backwards compatibility to older versions of OS X, which of course includes the libc++ on them. How does this proposal affect the future of such backwards compatibility?
In my specific case, I’m not intending to use future versions of Clang to target anything before OS X 10.10, but others may well do so.
This isn’t exactly the question that is being asked, but why GCC 4.7? Is it a particular feature that it provides, or is it important for other reasons?
When talking about GCC versions, I like to look at the version bundled with various Linux distributions.
Ubuntu 12.04 LTS (precise), released Apr-26-2012: GCC 4.6.3
Ubuntu 14.04 LTS (trusty), released Apr-17-2014: GCC 4.8.2
RHEL 6, released Nov-10-2010: GCC 4.4.7
RHEL 7, released Jun-10-2014: GCC 4.8.3
Is there one specific feature though? Here's the list of features and releases: Page Redirection - GNU Project
The thing that looks the most inconvenient to work around in 4.6 vs. 4.7 would probably be template aliases, and even that doesn't seem too horrible for c++03.
Going from 4.6 to 4.5 would result in the loss of nullptr and constexpr, and I can see those causing a heavy burden.
If you go the other direction though, you could argue that 4.8 would be beneficial, as then you get access to TLS.
Looking at the test-suite results I would say we have trouble supporting pre-4.9. But GCC 4.7 and 4.8 are bad implementations of C++11.
GCC 4.9 just works.
Libc++ 3.8 should require GCC 4.9 or newer because that’s what it actually needs. A C++11 feature complete compiler.
Below is a summary of how each GCC version does against the test-suite:
>
> We're having more and more trouble supporting pre-4.7 versions of gcc,
especially in C++03 mode.
>
> Much of the early gcc support was driven by the fact that Apple was
never going to move past gcc 4.2.1, and the necessity of supporting that
compiler - but that ship has sailed.
>
> I'd like to officially drop support for those compilers.
>
> Opinions?
In general, I’d be happy requiring a compiler that has full C++11 support
for building a C++11 standard library - doing otherwise seems odd. My one
concern (which I don’t think applies in this specific case) is on the
dependency between libc++ and clang. We need to make sure that there’s an
upgrade path that lets us bootstrap libc++ with an older clang, before
building a newer one.
Why would you build libc++ twice when bootstrapping? Either way, Libc++
will continue to build with older clangs for a long time to come.
I don't foresee a need to bootstrap it. I could only test Clang 3.2 but
that still builds libc++ flawlessly.
This may change once we need C++1z features compiled into the dylib though.
FWIW, I’m not aware of any users here at Google who care about anything before GCC 4.9. But we very much would like to have libc++ continue to support GCC 4.9. =]
Since Chandler and Eric are both pinging me: Android is using GCC 4.9 for all targets (and is very near not using GCC at all), and we’re not usually far behind ToT clang. We also don’t care about pre-C++11 support. The platform is C++14 and NDK users that want C++03 can use stlport.
I'm not trying to artificially limit support but I am trying to keep it
moving forward. With limited resources
I want to focus on support for C++1z and new libraries like filesystem. Most
libc++ users use clang,
and clang gave us full C++11 support in 3.0.It's time we demand it from
other compilers.
Doesn't libstdc++ require GCC? Or can it be compiled with Clang?
I'm already bootstrapping Clang to compile libc++ on ARM and AArch64,
as I got some compilation errors with GCC 4.8. I don't remember the
errors, as that was several months ago.
I doubt you can build libstdc++ with clang. Using libstdc++ from clang mostly works, but I’ve definitely had reports of certain pieces not working (particularly in places like and <type_traits>, iirc). Note that this was with libstdc++ 4.9. I don’t know if that has improved in 5+.
Hum, you're right. I completely forgot about this... We're tracking it
on in PR23529, but I don't see any recent progress.
I agree it's a disaster, but we'd have to make it work somehow if
we're going to support any future Linux distribution. Is there anyone
talking to the GNU guys about it?
There is some recent progress in the review thread about D12834 (didn’t make it to Phabricator) from sbergman. I don’t think there’s really anything to talk to the GCC people about – clang just needs to finish implementing the feature…
Oh, that's good to know. From the bug itself, it seemed the feature
wasn't mature enough in GCC, but if we're at that stage, and there are
no technical issues with the design, than I'll just wait for it.
> I'm not trying to artificially limit support but I am trying to keep it
> moving forward. With limited resources
> I want to focus on support for C++1z and new libraries like filesystem.
Most
> libc++ users use clang,
> and clang gave us full C++11 support in 3.0.It's time we demand it from
> other compilers.
Doesn't libstdc++ require GCC? Or can it be compiled with Clang?
We currently build chrome with clang and system libstdc++ (4.6) on linux,
so yes, this mostly works.
(But we only use libc++ with clang and gcc 4.9, so we don't care if libc++
drops support for older gccs. We don't care about C++03 support either.)
Ubuntu 12.04 LTS (precise), released Apr-26-2012: GCC 4.6.3
Ubuntu 14.04 LTS (trusty), released Apr-17-2014: GCC 4.8.2
Previous LTS is deprecated when a new LTS comes along, so no one
should have to worry about 12.04 in this day and age.
Is there any one that this is important?
12.04 may be deprecated, but it's still supported by Ubuntu until April 2017. There are plenty of IT departments that would be hesitant to roll out full OS upgrades once every two years.
Regardless, I don't build libcxx with the system GCC, I build with Clang. So long as libcxx can target libc from the 12.04 (and maybe even 10.04!) era, then I won't be personally affected.
