Re: [Boost-bugs] [Boost C++ Libraries] #7473: clang defines __GNUC__ and confuses the libstdcpp3.hpp configuration header

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #7473: clang defines __GNUC__ and confuses the libstdcpp3.hpp configuration header
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-05-19 11:08:51

#7473: clang defines __GNUC__ and confuses the libstdcpp3.hpp configuration header
--------------------------------------------------+-------------------------
  Reporter:  philipp.moeller@…                    |       Owner:  johnmaddock
      Type:  Bugs                                 |      Status:  closed     
 Milestone:  To Be Determined                     |   Component:  config     
   Version:  Boost 1.51.0                         |    Severity:  Problem    
Resolution:  wontfix                              |    Keywords:             
--------------------------------------------------+-------------------------

Comment (by johnmaddock):

 Here's the thing: I'm quite happy to apply a fix for this, but I just
 don't see how it can possibly be made to work.  To recap:

 * {{{__GLIBCXX__}}} is useless for this purpose as it reflect release
 date, not lib version.
 * {{{__clang_major__}}} tells us nothing about the std lib, only about
 Clang itself.
 * {{{__cplusplus}}} tells us nothing about the std lib, only Clang itself.
 * I can't see any internal libstdc++ macros can can be used for this
 purpose.
 * There's no way to tell whether the necessary patches (some official some
 not) have been applied to libstdc++, to pick one example recent versions
 of <type_traits> don't compile with {{{clang -std=gnu++11}}} because clang
 lacks {{{___float128}}}.  It's trivial to patch, but there's no official
 clang patch last time I looked.
 * Clang only claims to be compatible with GCC-4.2.1, frankly anything else
 is unsupported as far as I can see... even though use with later versions
 is very useful and what most of us actually do!

 Finally, if the user has to patch libstdc++, why not patch/configure boost
 as well?  At least Intel's compiler sets the GCC version number to match
 that of the underlying std lib which avoids all this nonsense.

 So... I don't see any way to fix this unless someone submits a patch that
 "works" and avoids the above pitfalls.  The only thing I could think of,
 would be to use {{{__GLIBCXX__}}} to detect libstdc++ features ''only''
 when the compiler is clang.  That would work some of the time, but break
 boost completely some of the time too, which frankly is not a path I want
 to take.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/7473#comment:10>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.