6

I am trying to test the version of libstdc++ because std::regex is implemented, but largely broken, in the versions of libstdc++ distributed with GCC before version 4.9.0.

Note that:

Is there any portable way to test the version of libstdc++ that does not depend on using GCC my compiler?

Community
  • 1
  • 1
Michael Koval
  • 8,207
  • 5
  • 42
  • 53
  • If you know that it's broken at a certain version, then test it to see if its broken, if it is, then you have the broken version, if not, then you have the working version. – ydobonebi Jul 19 '15 at 22:34
  • 1
    In practice, the best way to determine a version where no version is given, is to test against known behaviors. Just wanted to clarify that. Aside from that, what OS are you working with? I'm checking on windows if I can determine my ersion numbers or not... – ydobonebi Jul 19 '15 at 22:39
  • 1
    Quinn Roundy: I'd prefer to actually test the version. The bug only occurs at runtime, so I would have to compile (and execute) a test program as part of my build process. This could, potentially, break when cross-compiling. – Michael Koval Jul 19 '15 at 22:44
  • Try this http://stackoverflow.com/questions/10354636/how-do-you-find-what-version-of-libstdc-library-is-installed-on-your-linux-mac – ydobonebi Jul 19 '15 at 22:49
  • 1
    As a dependency to your main compilation, test behaviors that you know are broken in substandard versions.If it's broken, make the dependency `exit 1`, perhaps with a complaint. – David Hammen Jul 19 '15 at 23:03
  • Did you find a solution? I was thinking about testing the date of all versions for which libstdc++ is broken, but I cannot find a table of dates for each version anywhere... – gnzlbg May 09 '16 at 14:10

1 Answers1

-2

In my opinion the problem is sufficiently small to be solved by brute force.

In a header file called machine.hpp or similar I would test that the version of the C++ Standard is at least what I need it to be (the __cplusplus macro). Then I would add the various macro checks to reject any library that I know to be flawed.

In other words, I would take a black-list approach instead of a white-list approach.

For example:

#pragma once
#ifndef MACHINE_HPP_HEADER_GUARDS
#define MACHINE_HPP_HEADER_GUARDS

#if __cplusplus < 201103L
// Library is incompatible if it does not implement at least the C++11
// standard.
#error "I need a library that supports at least C++11."
#else
// Load an arbitrary header to ensure that the pre-processor macro is
// defined. Otherwise you will need to load this header AFTER you
// #include the header you care about.
#include <iosfwd>
#endif

#if __GLIBCXX__ == 20150422
#error "This version of GLIBCXX (20150422) has flaws in it"
#endif

// ...repeat for other versions of GLIBCXX that you know to be flawed

#endif // MACHINE_HPP_HEADER_GUARDS
Escualo
  • 40,844
  • 23
  • 87
  • 135
  • I am trying to figure out how to "add the various macro checks to reject any library that I know to be flawed." I can't figure out how to reliably check the version of `libstdc++` when building with a non-GCC compiler (e.g. Clang). – Michael Koval Jul 19 '15 at 22:52
  • Thanks for expanding your answer. However, this isn't a very maintainable solution. `__GLIBCXX__` does not increase monotonically, so I would have to edit this header every time a new version of GCC > 4.9 is released. – Michael Koval Jul 21 '15 at 19:44
  • @MichaelKoval that is not the case. Precisely that is why you only mark the compilers that you DO NOT want to use. When a new version of GCC comes out, you simply use it without any modification to the header. – Escualo Jul 21 '15 at 22:58
  • 1
    This bug is present in *all versions* of GCC 4.8. If a new version of GCC 4.8 is released, then the build will be broken until I blacklist the corresponding value of `__GLIBCXX__`. This is, unfortunately, not just a theoretical problem: two versions (4.8.4 and 4.8.5) were released in the last six months alone. – Michael Koval Jul 22 '15 at 00:09