Why is GCC using std::string instead of std::__cxx11::basic_string

this is not a duplicate of this because i am already using different versions. Please read the question and explanation before marking as a duplicate in 2 seconds. thank you for your patience and understanding I also do not think that this question is a duplicate as it still does not explain why is GCC's behaviour is like this, but more addresses the differences between gcc and g++.

I have manually installed GCC8.2.0 and compiled it from source and everything seemed to have worked out fine. Added the directory to /etc/ld.so.conf and ran again ldconfig. However when i test it, it is still using the old libstdc++ library. What am i missing?

#include <iostream>
#include <string>
int main()
{ std::string hey = "hello"; std::cout<<hey<<" world"<<std::endl; return 0;
}
gcc -D_GLIBCXX_USE_CXX11_ABI=1 test.cpp -std=c++17 -lstdc++ --verbose -o test -Wl,--verbose >link.txt

Compilation output:

Using built-in specs.
COLLECT_GCC=/usr/local/gcc8.2/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc8.2/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gcc-8.2.0/configure --prefix=/usr/local/gcc8.2 --disable-multilib --enable-languages=c,c++ --enable-threads
Thread model: posix
gcc version 8.2.0 (GCC)
COLLECT_GCC_OPTIONS='-D' '_GLIBCXX_USE_CXX11_ABI=1' '-std=c++17' '-v' '-o' 'test' '-mtune=generic' '-march=x86-64' /usr/local/gcc8.2/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/cc1plus -quiet -v -D_GNU_SOURCE -D _GLIBCXX_USE_CXX11_ABI=1 test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -std=c++17 -version -o /tmp/cctBaif9.s
GNU C++17 (GCC) version 8.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 8.2.0, GMP version 6.0.0, MPFR version 3.1.1, MPC version 1.0.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here: /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0 /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/x86_64-pc-linux-gnu /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/backward /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include /usr/local/include /usr/local/gcc8.2/include /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed /usr/include
End of search list.
GNU C++17 (GCC) version 8.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 8.2.0, GMP version 6.0.0, MPFR version 3.1.1, MPC version 1.0.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ffbbe768b373e36d4dbebee8b6dad361
COLLECT_GCC_OPTIONS='-D' '_GLIBCXX_USE_CXX11_ABI=1' '-std=c++17' '-v' '-o' 'test' '-mtune=generic' '-march=x86-64' as -v --64 -o /tmp/ccY7GV78.o /tmp/cctBaif9.s
GNU assembler version 2.30 (x86_64-redhat-linux) using BFD version version 2.30-47.el7
COMPILER_PATH=/usr/local/gcc8.2/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/local/gcc8.2/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/local/gcc8.2/libexec/gcc/x86_64-pc-linux-gnu/:/usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/:/usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-D' '_GLIBCXX_USE_CXX11_ABI=1' '-std=c++17' '-v' '-o' 'test' '-mtune=generic' '-march=x86-64' /usr/local/gcc8.2/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/collect2 -plugin /usr/local/gcc8.2/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/liblto_plugin.so -plugin-opt=/usr/local/gcc8.2/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccuLLh38.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test /lib/../lib64/crt1.o /lib/../lib64/crti.o /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtbegin.o -L/usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0 -L/usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../.. /tmp/ccY7GV78.o -lstdc++ --verbose -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtend.o /lib/../lib64/crtn.o
COLLECT_GCC_OPTIONS='-D' '_GLIBCXX_USE_CXX11_ABI=1' '-std=c++17' '-v' '-o' 'test' '-mtune=generic' '-march=x86-64'

Relevant part of the linking process:

attempt to open /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/libstdc++.so failed
attempt to open /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/libstdc++.a failed
attempt to open /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/libstdc++.so succeeded
-lstdc++ (/usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/libstdc++.so)
ls -lah /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/libstdc++.so
lrwxrwxrwx 1 root root 19 Jan 25 14:07 /usr/local/gcc8.2/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/libstdc++.so -> libstdc++.so.6.0.25

Problem:

nm -C a.out |grep string U std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)@@GLIBCXX_3.4 U std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()@@GLIBCXX_3.4 U 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::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)@@GLIBCXX_3.4

Why is this linking with such an old GLIBCXX_3.4, and how do I convince gcc (when called as gcc) to use the std::string I want it to?

20 Sorted by: Reset to default

Know someone who can answer? Share a link to this question via email, Twitter, or Facebook.

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy