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: wash (admin_at_[hidden])
Date: 2011-02-05 14:46:43

-----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.

>   - 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?

>       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.
 
>       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. 

>       4.6: presumably fails because of both generalized initializer
> lists and constexpr, neither of which Clang does not yet implement.

Confirmed.

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

Apache's stdlib is not functional.

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.

However, neither intel or the clang development team seem to be making efforts
to move their compilers away from the GNU stdlib on Linux. If I had more time, I
would invest time in making clang + linux + libc++ feasible, but I can't make
that investment at this point in time.

P.S. even if Apache's stdlib did work, Boost is not very Apache-stdlib friendly
- - this is partially the cause of Sun/Pathscale/HP compiler incompatibilty with
  Boost. A notable example: the MSVC and GNU stdlib implicitly include <ios>
  when <iostream>/<istream>/<ostream> is included, pulling in the manipulators
  which the standard says <ios> must define. Apache's stdlib does not pull in
  <ios> in these situations, as the Apache standard library is much more
  conservative about implicit includes. Improving Apache library compatibilty
  would require Boost-wide changes, and I'm certainly not touching that subject
  after recent events.

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.

- -- 
Bryce Lelbach aka wash
boost-spirit.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk1NqSMACgkQ9cB/V3/s9Ey/KgCdEuu8Dh8WY1ol1WKeW0ArPNuw
aEkAn1q2VIVsr4SKNu0PbHOXEUVteILB
=DhD2
-----END PGP SIGNATURE-----