This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] RFC: PR78905 define _GLIBCXX_RELEASE macro
On 17/01/17 17:16 -0500, Ed Smith-Rowland wrote:
On 01/17/2017 04:55 PM, Ed Smith-Rowland wrote:
On 01/17/2017 12:25 PM, Jonathan Wakely wrote:
As I said in https://gcc.gnu.org/ml/libstdc++/2017-01/msg00109.html
the __GLIBCXX__ macro is useless, but is the closest thing we have to
a version macro for libstdc++. This matters when using libstdc++ with
Clang or Intel icc or other compilers, because you can't check the
__GNUC__ macro. I've seen several requests for a way to check the
libstdc++ version, or complaints that there is no way to do it.
This patch adds a new _GLIBCXX_RELEASE macro that contains the same
value as __GNUC__ i.e. the major release number.
- Yes, it only contains the major number. We could in theory have
_GLIBCXX_MAJOR and _GLIBCXX_MINOR instead, but between
_GLIBCXX_RELEASE and __GLIBCXX__ you can identify the release branch
and a date within that branch.
- The name is "RELEASE" because we used to define _GLIBCXX_VERSION
many years ago, but it was a string literal and this is an integer.
To avoid problems for any old code checking for _GLIBCXX_VERSION I
chose a different name.
Thoughts?
PR libstdc++/78905
* include/Makefile.am (_GLIBCXX_RELEASE): Set value.
* include/Makefile.in: Regenerate.
* include/bits/c++config (_GLIBCXX_RELEASE): Add #define.
* testsuite/ext/profile/mutex_extensions_neg.cc: Use lineno of 0 in
dg-error.
This might stop people from complaining about stub implementations.
Yes, that's one way it could be helpful.
It would also help with ABI breaks and as a coarse-grained feature-macro.
Yes, the PR mentioned in the ChangeLog entry above is basically a
request for a feature-test macro for <regex>, but SD-6 doesn't define
macros for C++11 features (because it was written long after 2011 and
most implementations have full C++11 support now anyway).
It seems like we'd want to backport this of course.
I'm undecided. Would it still be useful to define _GLIBCXX_RELEASE=6
for the 6.4.0 release, even though it wasn't defined for 6.3.0? Maybe
it would be simpler to only define it from GCC 7 onwards. Or maybe
doing it for 5.5 and 6.4 would still be useful in some cases, even if
not in all cases.
Of course you want more feedback from packagers.
Ed
I'm assuming this is really directed at folks who borrow only the
library and not the rest of gcc.
Otherwise we could just use the main macro.
Yes, exactly. It's only useful when using libstdc++ with a non-GCC
compiler. That's fairly common, and if we remove this obstacle then
it's slightly easier to do, and there will be a good answer to
questions like:
http://stackoverflow.com/questions/21622561/how-to-detect-the-libstdc-version-in-clang
And Boost wouldn't need to do this for future releases:
https://github.com/boostorg/config/blob/develop/include/boost/config/stdlib/libstdcpp3.hpp#L116
If we backported it then Boost.Config could look for _GLIBCXX_RELEASE
first, and if it finds it use it, otherwise try that __has_include
dance.