Login/Register
Value of `__GLIBCXX__` for each libstdc++ release
Asked Answered
Solved c++linuxlibstdc++
B

3

5

The macro __GLIBCXX__ contains the time stamp of libstdc++ releases, e.g., from gcc documentation (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html)

__GLIBCXX__ The current version of libstdc++ in compressed ISO date format, as an unsigned long. For details on the value of this particular macro for a particular release, please consult the ABI Policy and Guidelines appendix.

I am looking for the values for all releases since the release of 4.9.0 (including releases of smaller versions like 4.8.x).

The documentation of libstdc++ does not seem to provide this information (it only provides the dates up to gcc 4.7.0).

Where can I find the values of __GLIBCXX__? Does anybody have them?

The ABI Policy and Guidelines appendix (https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html) says

Incremental bumping of a library pre-defined macro. For releases before 3.4.0, the macro is GLIBCPP. For later releases, it's GLIBCXX. (The libstdc++ project generously changed from CPP to CXX throughout its source to allow the "C" pre-processor the CPP macro namespace.) These macros are defined as the date the library was released, in compressed ISO date format, as an unsigned long.

but then only provides the values of the macro up to GCC 4.7.0. Still the day of a particular GCC releases are listed here:

https://gcc.gnu.org/releases.html

but for example for GCC 4.9.1 with release date "July 16, 2014" the ISO date format is 20140716 and the value of __GLIBCXX__ is 20140617 (notice the 7 and 6 have been switched).

Buddleia answered 9/5, 2016 at 14:16 Comment(8)
Are you sure v4.9.1 has a __GLIBCXX__ of 20140617? Because the source says it should be 20140716. – Zilvia
In my system it outputs 20140617. Weird. – Buddleia
That means you're using a snapshot from 20140617, not an official FSF release. – Eldoria
@JonathanWakely thanks, that kind of make the value useless for my purposes. – Buddleia
@JonathanWakely any ideas on how to detect in a header only library all libstdc++4.9.x versions? is there a macro for that? – Buddleia
Thanks for the information. For some reason I only landed on questions and answers that provided workarounds that do not work 100% instead of just saying "No, that cannot be done". Just wasted a lot of time on this but at least now its over. – Buddleia
See gcc.gnu.org/bugzilla/show_bug.cgi?id=69699 (stackoverflow is not authoritative, and people who say "don't link to external sites" are wrong ;-) – Eldoria
I did ping you and you are "authoritative" :P And wow, that's exactly the same problem I was trying to solve. The lack of is_trivially_xxx in 4.9.x but its presence on > 5.x releases (coupled with clang/gcc/libc++/libstdc++ support). – Buddleia
E
6

The information you want is useless anyway, so you should solve your problem a different way.

GCC 4.9.3 was released after GCC 5.3, so it has a later date in that macro, so you can't just do something like:

#if __GLIBCXX__ > 20150422 // GCC 5.1 release

because that would be true for 4.9.3, but that doesn't have all the features that 5.1 has.

Most GNU/Linux distros don't ship official FSF releases either, they build snapshots, which will have the date of the snapshot, which won't be in any list of release dates. And a snapshot from the 5.x branch on a given day will have the same date as a snapshot from the 6.x branch on a given day, so you can't tell them apart.

Eldoria answered 9/5, 2016 at 15:0 Comment(0)
Z
6

In the interest of answering the original question, here's a hacky command you can execute in your shell to get the list of releases and the value of __GLIBCXX__ for each release (starting with v4.1.0):

svn list "svn://gcc.gnu.org/svn/gcc/tags" | grep -o "gcc_\([^34]_.*\|4_[^0]_.*\)_release" | xargs -n 1 -I {} sh -c "printf \"{}: \" && svn cat svn://gcc.gnu.org/svn/gcc/tags/{}/gcc/DATESTAMP"

The results are:

Note that these values are from the official releases from the GCC team. If you're using an unofficial release, the values might differ slightly.

Zilvia answered 9/5, 2016 at 15:19 Comment(6)
Upvote for the list but please add a disclaimer that these values are only for the gcc releases distributed by the gnu organization via the gcc website. These values won't, in general, match with binary distributions provided by e.g. linux distributions or package managers. If the intent is to use these values to detect anything related to the actual compiler version these macros will provide wrong information. The only meaningful information that can be extracted from the __GLIBCXX__ macro is that the standard library implementation might be libstdc++. – Buddleia
@gnzlbg: Sure, I added a note clarifying that these values are from the official releases of the GCC team. But I'd personally consider that a bug for the distributions/package managers to release a package marked as vX.Y.Z and not have it actually match the authoritative, upstream version X.Y.Z (unless they've forked the project, in which case they should clearly mark it as a customized fork). – Zilvia
I don't find this nice either, but that's how most distributions work anyways. There are justifications for this, like when a patch fixes a security issue or solves a bug that prevents some other packages of the distro to compile the distro might decide to push a particular svn revision to their users between releases. And well some bleeding edge distros just push the most recent svn version on their releases. And well, there is also the future possibility that GCC releases two versions on the same date (e.g. 4.9.3 and 4.8.5 have very close time stamps). All this makes time stamps meaningless. – Buddleia
Note that these numbers are not in strictly ascending order (4.9.3 > 5.1.0). See svn.boost.org/trac10/ticket/7473 for how boost dealt with this problem and eventually came up with a solution. – Koffler
@gnzlbg, can you name one distribution that does mess with the __GLIBCXX__ definition? I've tested Fedora/RHEL 6/7/Ubuntu 14 LTS and they all behave as expected. – Sibilant
See also my answer for an improved command line - i.e. it uses https, it just issues one SVN request, and thus doesn't stresses the server as much and doesn't fork as much. – Sibilant
S
1

You can generate a list of possible __GLIBCXX__ values using the SVN release listing as source:

svn list --xml 'https://gcc.gnu.org/svn/gcc/tags' \
    | grep '>gcc.*release' -A4 \
    | grep 'name\|date' \
    | sed -e 's/<[^>]\+>//g' -e 's/T.*$//' -e 's/-//g' \
          -e 's/gcc_\|_release//g'  \
    | paste - -

A similar list, but more free-form and annotate with branching ascii art is maintained by the GCC team:

https://gcc.gnu.org/develop.html#timeline

Note that multiple release branches are active in parallel, cf e.g. the 4.8 and 4.9 branches:

4_8_0   20130322
4_8_1   20130531
4_8_2   20131016
4_8_3   20140522
4_8_4   20141219
4_8_5   20150623
4_9_0   20140422
4_9_1   20140716
4_9_2   20141030
4_9_3   20150626
4_9_4   20160803

Thus, unfortunately, you can't use a single date as simple cut-off value to determine a certain release.

Of course, you can auto-generate some helper macros from this list. Say - you need some workaround for the 4.8 GLIBCXX release (as used by GCC and different clang versions) then you could define a helper macro like this (after including some STL header):

#if        __GLIBCXX__ == 20130322 \
        || __GLIBCXX__ == 20130531 \
        || __GLIBCXX__ == 20131016 \
        || __GLIBCXX__ == 20140522 \
        || __GLIBCXX__ == 20141219 \
        || __GLIBCXX__ == 20150623
    #define HAVE_GLIBCXX_4_8     1
#else
    #define HAVE_GLIBCXX_4_8     0
#endif

If you are just interested in the major version and only need to support releases newer than GCC 7 than you can also use the _GLIBCXX_RELEASE macro.

Sibilant answered 2/11, 2018 at 20:25 Comment(2)
Is there also a macro (like _GLIBCXX_RELEASE) for the minor version of libstdc++? – Heartbreaker
@Heartbreaker No, there isn't. – Sibilant

© 2022 - 2024 — McMap. All rights reserved.