Subject: Re: [boost] Strange libstdc++ versions in travis-ci testers
From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2018-08-15 22:31:30
On Fri, 29 Jun 2018 at 03:56, Rene Rivera via Boost
> On Thu, Jun 28, 2018 at 9:11 PM Peter Dimov via Boost <boost_at_[hidden]>
> > Rene Rivera wrote:
> > > On Thu, Jun 28, 2018 at 4:40 PM Peter Dimov via Boost
> > > <boost_at_[hidden]> wrote:
> > >
> > > > To detect the actual libstdc++ version, you should use the
> > Boost.Config
> > > > macro, as it's generally more reliable.
> > >
> > > Why is it more reliable?
> > __GLIBCXX__ is a date, which is not very useful for determining the
> > version.
> Which is what Predef uses. And also uses __GLIBCPP__ as fallback. But, yes
> they are dates, as that's the only real indicator of *only* libstdc++ I
> knew of.
> There's _GLIBCXX_RELEASE but that's only for 7 and up. Config uses
> Hm, hadn't kept up on that. I'll have to add that if available.
which also has a link to
explaining why the __GLIBCXX__ and __GLIBCPP__ macros are useless for
determining the version.
> > __has_include to detect the version under Clang,
> How would __has_include help?
By checking for the presence of a header that was added in a
particular version. If <shared_mutex> is available, you're using at
least GCC 4.9
> > __GNUC__ under g++.
> But that's the g++ version, not the lib version.
When you're using g++ the lib version *is* the g++ version. Using
older or newer versions of libstdc++ with g++ is not supported, you
have to use the bundled one.
So when compiling with g++ the compiler version and the library
version are the same.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk