Re: [boost] [config][clang] Does <boost/config/compiler/clang.hpp> need updating?

Subject: Re: [boost] [config][clang] Does <boost/config/compiler/clang.hpp> need updating?
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2011-02-05 15:18:08

On Sat, Feb 5, 2011 at 11:46 AM, Bryce Lelbach
<admin_at_[hidden]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, 5 Feb 2011 10:26:20 -0800
> Doug Gregor <doug.gregor_at_[hidden]> wrote:
>
>> Clang itself is just now getting some C++0x support. It has rvalue
>> references, variadic templates, decltype, static_assert, and some
>> other goodies. We think it's in decent shape, but obviously we need
>> more testing coverage.
>
> On Darwin. On Linux, clang C++0x support is a moot point because clang-linux
> uses the GNU stdlib. Also, according to the regression tests, clang + libc++
> can't compile most of Boost.

If you're referring to the clang-darwin-libcxx and
clang-darwin-libcxx0x testers, a number of failures I looked at were
configuration-related, where clang++ wasn't being told to link against
libc++. That needs to be sorted out before we can get to the real
failures. I suspect it's that clang-darwin et al. need to be taught
how to change the standard library.

>>   - libc++ (Clang/LLVM's new C++0x standard library) works great with
>> Clang's C++0x support.
>
> libc++'s build system is very Mac centric. The last time I tried to use it on
> Linux, I was unsuccessful in doing so, because the build system relied on the
> existance of a darwin centric build tool. Has this situation changed? Is libc++
> supported on Linux?

Yes, it's still a major pain to get libc++ working on Linux. That's a
separate issue whose discussion belongs elsewhere.

>>       4.3, 4.4: fails, because the library was written at a time when
>> rvalue references could bind to lvalues, which they now can't. so,
>> Clang C++0x (correctly) rejects the code. This is just a casualty of
>> shipping compilers and libraries based on an incomplete working paper.
>
> 4.3 and 4.4 are usable on Linux if C++0x support is disabled. At least, my
> version of clang is. Mainstream clang was, last time I checked.

Right, 4.3 and 4.4 aren't interesting when looking at C++0x support.

>>       4.5: fails, because the library uses generalized initializer
>> lists, which Clang does not yet implement.
>
> 4.5 is semi-usable on Linux - there used to be a boost workaround for the
> <iomanip> header with 4.5. This was removed.

Okay, it works if you never end up including <iomanip>. That's not a
definition of "works" we should advertise :)

>> (I haven't tried Dinkumware or Apache; I suspect they'll need
>> to be taught about Clang first).
>
> Apache's stdlib is not functional.

Okay.

> Part of the problem here is that GNU seems to make a policy of changing working
> parts of their C++(03/99) stdlib to use C++0x features that only G++ supports,
> without leaving the old, working C++03/C++99 code in place (the <iomanip> header
> change from 4.4 to 4.5 is an excellent example of this). Given that both Apple
> and Intel are targets of GNU's political attacks these days, and given that both
> Clang (an Apple supported compiler) and the intel compiler use the GNU stdlib on
> Linux, I suspect that GNU is intentionally trying to poison intel-linux and
> clang-linux.

The more positive view of this situation is that they're nudging these
vendors to implement C++0x features, so we can all have a better C++0x
standard and start using these features in our day-to-day work. At
least, that was my goal when I put C++0x features into libstdc++ :)

> However, neither intel or the clang development team seem to be making efforts
> to move their compilers away from the GNU stdlib on Linux.

Binary compatibility dictates that all of the compilers on the system
use the same standard library. Hence, you'll continue to see these
compilers supporting the GNU stdlib so long as it is the dominant
standard library on the system.

> P.S.S. dgregor, don't get me wrong. I really like clang, and I think you guys
> are doing an excellent job. I have a TON of respect for you. As you probably
> know, I use clang as my primary compiler, and I invested a substantial amount
> of time compiling the Linux kernel with clang. I am saddened by the
> darwin-centric focus that I see in clang. I understand that a good portion of
> the clang development team is employeed by Apple, and I get that darwin is your
> focus. But things like the libc++ build system bother me. It would be a simple
> matter to make libc++ Linux friendly, and that would probably encourage Debian-
> and Redhat-maintainers of clang packages to ship clang on Linux with libc++ as
> the default standard library.

We're way out scope for the Boost list, so I'll be super-brief: if it
were a "simple matter", someone would have done it by now.

  - Doug