【linuxs make 出现undefined reference to ‘std::__cxx11...】

类似这种：

解释一：

在CentOS系统上安装了gcc4.8.2和gcc7.2两个版本，gcc使用的是4.8.2版本，g++使用的是7.2版本，使用make编译cmake时出现c++11标准库未定义错误，两个版本的编译器使用的库版本也不同，对c++11标准的实现程度也不一样，所以会出现该问题，将g++换成4.8.2版本即解决该问题。
个人感觉编译器报标准库的错误很可能就是工具链版本的问题，修改使用合适的工具链应该即可，比如对gcc软件，所有编译器都使用统一版本即可。

————————————————
版权声明：本文为CSDN博主「璞小坤」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/walker_0_/article/details/83041846

解释二：

关于编译报错 error: cannot convert ‘const std::__cxx11::basic_string’ to ‘const char*’ 的处理

所以然

目前c++11标准开始普及，大家都开始默认支持或者使用c++11，例如GCC 5就开始默认启用C++11特性。但是由于c++11相对于c++03，很多实现的数据结构都发生了改变，所以两者并不能完全混用。
默认情况下，GCC 5在编译时会将std::string类型按c++11下std::__cxx11::basic_string 来处理，这时如果你调用的库在编译时未启用c++11特性则其中的std::string实际上是std::basic_string ，这时如果将c++11下的string当作参数传入非c++11的库时，就会出现error: cannot convert ‘const std::__cxx11::basic_string’ to ‘const char*’，或者未定义的方法引用（undefined reference）。

然

如果你是在GCC5下使用了非GCC5编译的库，或者编译时关闭了c++11特性的库，那么在编译你的代码时请相应的关闭C++11特性：

• 0x01 编译选项中预定义宏

> -D_GLIBCXX_USE_CXX11_ABI=0

在cmakelists里面要怎么修改呢：

> add_definitions(-D_GLIBCXX_USE_CXX11_ABI=0)
> 或者
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D_GLIBCXX_USE_CXX11_ABI=0")

还有如果用用cmake编译加参数要怎么修改呢：

> cmake -D_GLIBCXX_USE_CXX11_ABI=0 ../

后面的…/是你的CMakeLists相对于当前的路径

• 0x02 代码中定义宏

> #define _GLIBCXX_USE_CXX11_ABI 0

• 0x03 通过其他方法定义 _GLIBCXX_USE_CXX11_ABI 宏的值为0
  例如Qt中可以在Pro文件中添加:

> DEFINES += _GLIBCXX_USE_CXX11_ABI=0

————————————————
版权声明：本文为CSDN博主「ufolr」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ufolr/article/details/52669333

当然了少不了官方的说明：

添加链接描述

Dual ABI
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. （在GCC 5.1版本中，libstdc++引入了一个新的库ABI，它包括新的std:：string和std:：list实现。这些更改是必要的，以符合2011 C++标准，该标准禁止在写入字符串上复制，并要求列表跟踪其大小。）
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 is actually defined as std::__cxx11::list. Because the symbols for the new implementations have different names the definitions for both versions can be present in the same library. （在GCC 5.1版本中，libstdc++引入了一个新的库ABI，它包括新的std:：string和std:：list实现。这些更改是必要的，以符合2011 C++标准，该标准禁止在写入字符串上复制，并要求列表跟踪其大小。）
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(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 use strings, most 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.
One exception type does change when using the new ABI, namely std::ios_base::failure. This is necessary because the 2011 standard changed its base class from std::exception to std::system_error, which causes its layout to change. Exceptions due to iostream errors are thrown by a function inside libstdc++.so, so whether the thrown exception uses the old std::ios_base::failure type or the new one depends on the ABI that was active when libstdc++.so was built, not the ABI active in the user code that is using iostreams. This means that for a given build of GCC the type thrown is fixed. In current releases the library throws a special type that can be caught by handlers for either the old or new type, but for GCC 7.1, 7.2 and 7.3 the library throws the new std::ios_base::failure type, and for GCC 5.x and 6.x the library throws the old type. Catch handlers of type std::ios_base::failure will only catch the exceptions if using a newer release, or if the handler is compiled with the same ABI as the type thrown by the library. Handlers for std::exception will always catch iostreams exceptions, because the old and new type both inherit from std::exception.

最后我的原因是：有个库用的gcc高版本编译的，所以给他换成我现在使用的低版本编译就好了。