Why does STL code seem to be statically linked into the Boost dynamic libraries on Darwin?
When I build Boost 1.42/1.46.1/1.49 on OS X with gcc 4.6.1 and toolset=darwin, I find that the resulting libraries statically include a lot of STL code, such as std::basic_string<char> and std::basic_string<wchar_t>.
Building on OS X 10.6.8, I get the following results:
% otool -L /usr/local/boost-1.46.1/lib/libboost_system.dylib
boost-1.46.1/lib/libboost_system.dylib:
libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
Based on the 'otool -L' output, it's clear that libstdc++ is not dynamically linked with the library. By comparison, on Ubuntu 12.04 LTS, libboost_system.so 1.46.1 shows the following linking:
% ldd /usr/local/lib/libboost_system.so
linux-vdso.so.1 => (0x00007fff495ff000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fec4edb4000)
libstdc++.so.6 => /usr/local/lib64/libstdc++.so.6 (0x00007fec4ea82000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fec4e788000)
libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00007fec4e573000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fec4e355000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec4df98000)
/lib64/ld-linux-x86-64.so.2 (0x00007fec4f1e4000)
In this case libstdc++ has clearly been dynamically linked. On the OS X side, this is how I know that STL code has been included directly in the Boost library:
% nm -gfj /usr/local/boost-1.46.1/lib/libboost_system.dylib | c++filt --format=gnu-v3 | egrep "^std::basic_string"
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_disjunct(char const*) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char const*, unsigned long) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char const*, unsigned long, unsigned long) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long) const
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char, unsigned long) const
... [180 more lines] ...
Just to pick on one example:
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::find_last_of(char const*, unsigned long) const
std::basic_string is a template class, and does not exist in libstdc++.dylib. It was instantiated when the boost library was compiled, and (rightly) included there - because Boost.System uses it.
I suspect (but don't know) that this is true for all of the calls you see.
Related
I'm trying to link against a 3rd party library that uses Boost. I've linked against the correct boost library (libboost_program_options.a), but still not finding it.
The error msg (formatted a bit for clarity):
undefined reference to `boost::program_options::validate(boost::any&,
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&,
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*,
int)'
nm --demangle libboost_program_options.a | grep validate
boost::program_options::validate(boost::any&, std::vector<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > > const&,
bool*,
int)
boost::program_options::validate(boost::any&,
std::vector<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > > const&,
std::string*,
int)
boost::program_options::validate(boost::any&,
std::vector<std::string, std::allocator<std::string> > const&,
bool*,
int)
boost::program_options::validate(boost::any&,
std::vector<std::string, std::allocator<std::string> > const&,
std::string*,
int)
The second record looks similar, but apparently not close enough. Any idea how I can compile Boost to get a signature that matches what's in the library? I have a request out to the library owner to see what version of Boost they're using and such, but haven't heard back yet.
This is on a CentOS 7 box, which uses g++ version 4.8.5. But the library I'm tryng to link against uses C++11 heavily and was compiled with g++ v 6.1, so I installed devtoolset-6 which gives me a g++ 6 environment (g++ version 6.3.1)
I downloaded and built Boost from scratch (v1.65.1) so that it's built with the same compiler, rather then the system version.
Edit...
I think John Zwinck is on the right track, but I can't get the boost library to compile to the new ABI.
The validate() functions are found in value_semantic.cpp
Stripping the build down to the basics, and adding the flags discussed:
g++ -std=c++11 -D_GLIBCXX_USE_CXX11_ABI -c -o test.o libs/program_options/src/value_semantic.cpp
nm --demangle test.o | grep validate
00000000000008b6 T boost::program_options::validate(boost::any&, std::vector<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > > const&, bool*, int)
0000000000000c02 T boost::program_options::validate(boost::any&, std::vector<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > > const&, std::string*, int)
00000000000005f2 T boost::program_options::validate(boost::any&, std::vector<std::string, std::allocator<std::string> > const&, bool*, int)
0000000000000b9a T boost::program_options::validate(boost::any&, std::vector<std::string, std::allocator<std::string> > const&, std::string*, int)
Does the _GLIBCXX_USE_CXX11_ABI macro only work with gcc 5.1?
It appears you have run afoul of the GCC Dual ABI for std::string in C++11: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
Your program is trying to link against an API using
std::__cxx11::basic_string<char>*
But your Boost library has
std::basic_string<char>*
This implies that your Boost library was built with GCC older than 5.1, or with the new ABI turned off. In either case, you can compile your own code with the new ABI turned off by adding this compiler flag:
-D_GLIBCXX_USE_CXX11_ABI=0
By compiling your program with that, it will be possible to use the system-provided (old ABI) Boost libraries. But then the question will be which C++ ABI your vendor compiled their code with (ask them, or look for __cxx11 in their library).
As explained at https://stackoverflow.com/a/52611576/981959 you can't use the new cxx11 ABI in the devtoolset version of GCC (because the whole point of the devtoolset GCC is to remain compatible with the system libstdc++'s ABI).
Your options are to either:
get a new version of the third-party library that uses the gcc4-compatible ABI, so you can link to it using the devtoolset compiler; or
build and install a newer GCC yourself, use that instead of the devtoolset GCC, and ensure that the new libstdc++.so gets used at runtime.
Ok, I think I've figured out why I can't get g++ to generate the cxx11 signature (new ABI).
If I run g++ with the -v option:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-6/root/usr/libexec/gcc/x86_64-redhat-linux/6.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-6/root/usr --mandir=/opt/rh/devtoolset-6/root/usr/share/man --infodir=/opt/rh/devtoolset-6/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-plugin --with-linker-hash-style=gnu --enable-initfini-array --disable-libgcj --with-default-libstdcxx-abi=gcc4-compatible --with-isl=/builddir/build/BUILD/gcc-6.3.1-20170216/obj-x86_64-redhat-linux/isl-install --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.3.1 20170216 (Red Hat 6.3.1-3) (GCC)
Note the following under the "configured with" field
--with-default-libstdcxx-abi=gcc4-compatible
What I believe this means is that the devtoolset-6 version of g++ is built with the old style ABI "baked in", and it therefore doesn't respond to the _GLIBCXX_USE_CXX11_ABI macro.
According to this link: https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
--with-default-libstdcxx-abi=OPTION
Set the default value for the _GLIBCXX_USE_CXX11_ABI macro (see Macros). The default is OPTION=new which sets the macro to 1, use OPTION=gcc4-compatible to set it to 0. This option does not change the library ABI.
It would seem to only change the default value of _GLIBCXX_USE_CXX11_ABI, but in my attempts setting _GLIBCXX_USE_CXX11_ABI doesn't have any effect.
Not positive of this, but it's my working theory for now. Any additional insight is appreciated.
I try to understand how to overcome problems with the dual ABI introduced in GCC 5. However, I don't manage to do it. Here is a very simple example to reproduce errors. The version of GCC I use is 5.2. As you can see, my main function (in main.cpp file) is quite simple:
// main.cpp
#include <iostream>
#include <string>
int main()
{
std::string message = "SUCCESS!";
std::cout << message << std::endl;
}
When I type
/home/aleph/gcc/5.2.0/bin/g++ main.cpp
I get the following error message:
/tmp/ccjsTADd.o: In function `main':
main.cpp:(.text+0x26): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)'
main.cpp:(.text+0x43): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <char, std::char_traits<char>, std::allocator<char> >(std::basic_ostream<char, std::char_traits<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
main.cpp:(.text+0x5c): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
main.cpp:(.text+0x8c): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
collect2: erreur: ld a retourné 1 code d'état d'exécution
If I change the value of _GLIBCXX_USE_CXX11_ABI to 0, the problem disappears.
But, how to make things work with the default ABI?
EDIT: simpler question (removed cmake script)
I found the solution by adding more verbosity to gcc (-v flag). If you have the same problem, you need to tell gcc to search for libraries in the repository containing the libstdc++ version of your distribution. In other words, you should try something like this:
/home/aleph/gcc/5.2.0/bin/g++ -L /home/aleph/gcc/5.2.0/lib64 main.cpp
The linking step should be correctly performed after that. However, you may not be able to run your program. Entering
./a.out
may lead to the following error:
./a.out: relocation error: ./a.out: symbol _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference
Indeed, you can check that your executable depends on the wrong version of libstdc++ by typing
ldd a.out
which should lead to something like that:
linux-vdso.so.1 => (0x00007ffebb722000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x0000003a71400000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000003d03a00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000003a71000000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000003d02e00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003d02a00000)
Set LD_LIBRARY_PATH to the path to your own version of libstdc++ will solve the problem:
LD_LIBRARY_PATH=/home/aleph/gcc/5.2.0/lib64 ./a.out
Hope it helps!
EDIT: as noticed by Marc, it is possible to modify the rpath, instead of modifying the environment variable LD_LIBRARY_PATH. Here is a CMake configuration script to do it.
project (example CXX)
add_executable(main main.cpp)
if(GCC_ROOT)
set(CMAKE_CXX_COMPILER ${GCC_ROOT}/bin/g++)
target_link_libraries(main ${GCC_ROOT}/lib64/libstdc++.so)
link_directories(${GCC_ROOT}/lib64)
endif(GCC_ROOT)
This script can be used with the usual combo
cmake ..
make
in a 'build' subdirectory. But it is also possible to choose our own compilers by providing the path to the root of our GCC distribution:
cmake -D GCC_ROOT=/home/aleph/gcc/5.2.0 ..
make
The script is written so that the version of libstdc++ corresponds to the version of the input GCC distribution.
I am using the boost libraries for a project, and I am running into issues with the regex library. I am re-installing the libraries because I have upgraded to osx 10.9 (mavericks).
I am getting 2 undefined references for :
boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >::maybe_assign(boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > const&)
and
boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags)
I am installing the boost libraries from source, specifically because I do not want to be using macports or any outside package installer. The reason is that my program is used in the mathematics and scientific community, and I am trying to keep it so that it can easily compiled from source with the appropriate dependencies (i.e. linking to certain libraries like gmp and mpfr, and, at least for now, boost).
The undefined reference issue is occurring regardless of the compiler I've used. That is, I have installed gcc 4.7.3 with apple's default compiler from the command line developer's tools. So this occurs for both gcc4.7.3 AND the default g++ (apple's clang, version 4.2.1).
This is a parallel application, so I have two versions of mpich3 installed, both compiled with the above 2 compilers and installed and built in separate directories.
When I built boost, I edited the user-config.jam file and added the lines
using gcc : 4.7.3 : "abs\loc\here" ;
and
using mpi ;
Then I ran sudo ./bootstrap.sh ; sudo ./b2 ; sudo ./b2 install (with the sudo being necessary as the installation files are in a /usr/local subdir)
Anyway, the file that is using the boost libraries is called para_aux_funcs.hpp / para_aux_funcs.cpp, and I am compiling with (well, after a Makefile that produces this for me to make all .o files from the .cpp ones ):
/usr/local/mpich3-mac-default/bin/mpic++ -cxx=/usr/local/bin/g++ -I/Users/matthewniemerg/Research/Bertini/Current/BertiniSource_v1.4/include -I/usr/local/boost_1_50_0/include -I../include -Dtimingstep2 -DTIXML_USE_STL -Wall -O3 -funroll-loops -fexpensive-optimizations -fopenmp -c para_aux_funcs.cpp -L/usr/local/boost_1_50_0/lib -lboost_regex -lboost_system -lboost_filesystem -o para_aux_funcs.o
I've also done this with the other mpi installation with the appropriate -cxx flag passed to indicate which compiler was used for the mpi compilation. And, I've also switch the order of where the -L and -l flags go in the above command, but with the same results.
That is, the following command gives me the undefined references indicated above:
/usr/local/mpich3-mac-default/bin/mpic++ -cxx=/usr/local/bin/g++ -I/Users/matthewniemerg/Research/Bertini/Current/BertiniSource_v1.4/include -I/usr/local/boost_1_50_0/include -I../include -Dtimingstep2 -DTIXML_USE_STL -Wall -O3 funroll-loops -fexpensive-optimizations -fopenmp -o paramotopy paramotopy.o point.o datagatherer.o failed_paths.o menu_cases.o master.o slave.o step2readandwrite.o runinfo.o mtrand.o random.o step2_funcs.o step1_funcs.o timing.o tinyxmlerror.o tinyxml.o tinystr.o tinyxmlparser.o xml_preferences.o para_aux_funcs.o ../lib/libbertini_osx9.a -lm -lmpfr -lgmp -L/usr/local/boost_1_50_0/lib -lboost_regex -lboost_system -lboost_filesystem
This looks like a linking error, but I am linking the libraries (i.e. -l flag) and pointing to the appropriate directories for where the library is located (i.e. -L flag) and indicating where the appropriate header files are (i.e. -I flag).
Any thoughts / ideas?
I'm trying to compile one of the boost::program_options examples, http://svn.boost.org/svn/boost/trunk/libs/program_options/example/first.cpp, using gcc 4.8 (installed via MacPorts). However, I keep getting errors:
Undefined symbols for architecture x86_64:
"boost::program_options::to_internal(std::basic_string, std::allocator > const&)", referenced from:
std::vector, std::allocator >, std::allocator, std::allocator > > > boost::program_options::to_internal, std::allocator > >(std::vector, std::allocator >, std::allocator, std::allocator > > > const&) in ccEWnIGV.o
"boost::program_options::options_description::options_description(std::basic_string, std::allocator > const&, unsigned int, unsigned int)", referenced from:
_main in ccEWnIGV.o
"boost::program_options::invalid_option_value::invalid_option_value(std::basic_string, std::allocator > const&)", referenced from:
void boost::program_options::validate(boost::any&, std::vector, std::allocator >, std::allocator, std::allocator > > > const&, double*, long) in ccEWnIGV.o
"boost::program_options::error_with_option_name::error_with_option_name(std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&, int)", referenced from:
boost::program_options::validation_error::validation_error(boost::program_options::validation_error::kind_t, std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&, int) in ccEWnIGV.o
"boost::program_options::detail::cmdline::set_additional_parser(boost::function1, std::allocator >, std::basic_string, std::allocator > >, std::basic_string, std::allocator > const&>)", referenced from:
boost::program_options::basic_command_line_parser::extra_parser(boost::function1, std::allocator >, std::basic_string, std::allocator > >, std::basic_string, std::allocator > const&>) in ccEWnIGV.o
"boost::program_options::detail::cmdline::cmdline(std::vector, std::allocator >, std::allocator, std::allocator > > > const&)", referenced from:
boost::program_options::basic_command_line_parser::basic_command_line_parser(int, char const* const*) in ccEWnIGV.o
"boost::program_options::operator >&, boost::program_options::options_description const&)", referenced from:
_main in ccEWnIGV.o
"boost::program_options::abstract_variables_map::operator[](std::basic_string, std::allocator > const&) const", referenced from:
boost::program_options::variables_map::operator[](std::basic_string, std::allocator > const&) const in ccEWnIGV.o
"boost::program_options::error_with_option_name::substitute_placeholders(std::basic_string, std::allocator > const&) const", referenced from:
vtable for boost::program_options::invalid_option_value in ccEWnIGV.o
vtable for boost::program_options::validation_error in ccEWnIGV.o
etc...
The boost libraries were installed via MacPorts, placing the header files in /opt/local/include and library files in /opt/local/lib. The compile command used was:
$ g++ -I/opt/local/include first.cpp -L/opt/local/lib -lboost_program_options-mt
Compiling header-only boost functions work fine using g++ 4.8 i.e factorial, hermite etc.
What I find strange is that this example compiles if I use the llvm-g++ compiler:
$ llvm-g++ -I/opt/local/include first.cpp -L/opt/local/lib -lboost_program_options-mt
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.1/lto-wrapper
Target: x86_64-apple-darwin12
Thread model: posix
gcc version 4.8.1 (MacPorts gcc48 4.8.1_3)
\
$ llvm-g++ -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
\
Why doesn't this example compile with gcc 4.8? Any ideas? Is there a way to fix this?
Update: The example also compiles using clang++
I suspect you're using Boost compiled with Clang, which is incompatible with GCC.
This is because C++ implementation differs between them, and Clang's STL classes are put in a namespace different from GCC's using inline namespace for the sake differentiating Clang from more popular GCC; e.g. std::basic_string is std::__1::basic_string in Clang by inline namespace).
Try a command below, If you see "libc++" in output, yes, your Boost was built with Clang (or "libstdc++" for GCC):
$ otool -L /opt/local/lib/libboost_program_options-mt.dylib
/opt/local/lib/libboost_program_options-mt.dylib:
/opt/local/lib/libboost_program_options-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
If Boost was built with Clang, I recommend you to rebuild Boost with GCC-4.8 provided by MacPorts:
sudo port upgrade --force boost configure.compiler=macports-gcc-4.8
You can find other available compilers in https://trac.macports.org/wiki/UsingTheRightCompiler#configure-compiler .
Other useful link:
http://wiki.inkscape.org/wiki/index.php/CompilingMacOsX#Compiling_with_clang_3.3_and_libc.2B.2B_.28c.2B.2B11_enabled.29_.282013.29
As Shigerello already mentioned, the problem lies in boost compiled with clang and boost compiled with gcc being incompatible.
A simpler variation to get boost compiled with GCC-4.8 is to just use the gcc48 variant of boost:
sudo port install boost +gcc48
Not sure what issue I am having here.
Mac clang 3.1 cmake
gtest
few files
using few C++11 features
I have downloaded and installed XCode build tools
CMAKE_CXX_FLAGS = -Wall -std=c++0x -stdlib=libc++ -v
builds fine with output...
[100%] Building CXX object CMakeFiles/soupbintcptest.dir/soupmessages_tests.cpp.o
clang version 3.1 (tags/RELEASE_31/final)
Target: x86_64-apple-darwin11.3.0
Thread model: posix
Linking dumps a slew of errors. ABI errors? I know there is this C++11 namespace mangling thing happening.
Undefined symbols for architecture x86_64:
They are all things in the std:: namespace that will not link like:
"std::basic_ostream<char, std::char_traits<char> >& std::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, std::_Setprecision)", referenced from:
testing::AssertionResult testing::internal::FloatingPointLE<float>(char const*, char const*, float, float) in libgtest.a(gtest-all.cc.o)
testing::AssertionResult testing::internal::FloatingPointLE<double>(char const*, char const*, double, double) in libgtest.a(gtest-all.cc.o)
testing::Message::Message() in libgtest.a(gtest-all.cc.o)
or
"std::cerr", referenced from:
testing::internal::GTestLog::GetStream() in libgtest.a(gtest-all.cc.o)
"std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()", referenced from:
testing::UnitTest::AddTestPartResult(testing::TestPartResult::Type, char const*, int, testing::internal::String const&, testing::internal::String const&) in libgtest.a(gtest-all.cc.o)
testing::internal::SingleFailureChecker::~SingleFailureChecker() in libgtest.a(gtest-all.cc.o)
testing::internal::StringStreamToString(std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >*) in libgtest.a(gtest-all.cc.o)
testing::TestInfo::TestInfo(char const*, char const*, char const*, char const*, void const*, testing::internal::TestFactoryBase*) in libgtest.a(gtest-all.cc.o)
testing::TestInfo::~TestInfo() in libgtest.a(gtest-all.cc.o)
testing::internal::ReportInvalidTestCaseType(char const*, char const*, int) in libgtest.a(gtest-all.cc.o)
testing::internal::XmlUnitTestResultPrinter::PrintXmlUnitTest(__sFILE*, testing::UnitTest const&) in libgtest.a(gtest-all.cc.o)
...
I believe I have built gtest with the same clang++ version. Not sure what else is going on here to drive these issues.
I've seen similar errors to yours when the linker is pulling in a different c++ library to the one that matches what the compiler is building for. In your case, you are only modifying the compiler flags, but the linker doesn't know your choice and is likely linking to the wrong C++ library.
If you are able to use CMake 3.2 or later, then rather than modifying the C++ compiler flags directly, I'd recommend you just tell CMake you want to use C++11 and then let it work out the appropriate compiler and linker flags for you. This can be done by adding the following before your project() call:
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
This and related CMake features are discussed in detail in this article.
There is nothing C++11 about name mangling, it's been going on since the very first C++ implementations. However, do not forget that you must have built gtest for the same stdlib switch, because it can't find the Standard libraries.