In the GCC 5.1 release libstdc++ introduced a new library ABI that
  includes new implementations of std::string and
  std::list. These changes were necessary to conform
  to the 2011 C++ standard which forbids Copy-On-Write strings and requires
  lists to keep track of their size.
 In order to maintain backwards compatibility for existing code linked
  to libstdc++ the library's soname has not changed and the old
  implementations are still supported in parallel with the new ones.
  This is achieved by defining the new implementations in an inline namespace
  so they have different names for linkage purposes, e.g. the new version of
  std::list<int> is actually defined as
  std::__cxx11::list<int>. Because the symbols
  for the new implementations have different names the definitions for both
  versions can be present in the same library.
 The _GLIBCXX_USE_CXX11_ABI macro (see
Macros) controls whether
  the declarations in the library headers use the old or new ABI.
  So the decision of which ABI to use can be made separately for each
  source file being compiled.
  Using the default configuration options for GCC the default value
  of the macro is 1 which causes the new ABI to be active,
  so to use the old ABI you must explicitly define the macro to
  0 before including any library headers.
  (Be aware that some GNU/Linux distributions configure GCC 5 differently so
  that the default value of the macro is 0 and users must
  define it to 1 to enable the new ABI.)
 Although the changes were made for C++11 conformance, the choice of ABI
  to use is independent of the -std option used to compile
  your code, i.e. for a given GCC build the default value of the
  _GLIBCXX_USE_CXX11_ABI macro is the same for all dialects.
  This ensures that the -std does not change the ABI, so
  that it is straightforward to link C++03 and C++11 code together.
 Because std::string is used extensively
  throughout the library a number of other types are also defined twice,
  including the stringstream classes and several facets used by
  std::locale. The standard facets which are always
  installed in a locale may be present twice, with both ABIs, to ensure that
  code like
  std::use_facet<std::time_get<char>>(locale);
  will work correctly for both std::time_get and
  std::__cxx11::time_get (even if a user-defined
  facet that derives from one or other version of
  time_get is installed in the locale).
 Although the standard exception types defined in
  <stdexcept> use strings, they
  are not defined twice, so that a std::out_of_range
  exception thrown in one file can always be caught by a suitable handler in
  another file, even if the two files are compiled with different ABIs.
 If you get linker errors about undefined references to symbols
  that involve types in the std::__cxx11 namespace or the tag
  [abi:cxx11] then it probably indicates that you are trying to
  link together object files that were compiled with different values for the
  _GLIBCXX_USE_CXX11_ABI macro. This commonly happens when
  linking to a third-party library that was compiled with an older version
  of GCC. If the third-party library cannot be rebuilt with the new ABI then
  you will need to recompile your code with the old ABI.
 Not all uses of the new ABI will cause changes in symbol names, for
  example a class with a std::string member variable
  will have the same mangled name whether compiled with the old or new ABI.
  In order to detect such problems the new types and functions are
  annotated with the abi_tag attribute, allowing the
  compiler to warn about potential ABI incompatibilities in code using them.
  Those warnings can be enabled with the -Wabi-tag option.