GCC not using proper version of std::string

Question

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?

Shouldn't it have exactly same output?. Tried it, now it uses the correct version of td::__cxx11::basic_string. but how? — eucristian, Jan 25 '19 at 15:31
`gcc` is for compiling and linking c programs, `g++` is for c++, although they are symlinks to the same program gcc behaves differently based on which symlink is used to start them (clang does the same) — Alan Birtles, Jan 25 '19 at 15:35
So can i get the same behaviour of gcc as for g++? I mean when i invoke gcc to compile this to use proper GLIBCXX_ ? which symlink should i search for gcc --version gcc (GCC) 8.2.0 — eucristian, Jan 25 '19 at 15:38
@eucristian "So can i get the same behaviour of gcc as for g++" - Why? Just compile C++ code with g++ like everyone else and move on... — Jesper Juhl, Jan 25 '19 at 15:43
I am not sure that my problem has been solved: std::__cxx11::basic_string, std::allocator >::~basic_string() U std::basic_ostream >& std::operator<< , std::allocator >(std::basic_ostream >&, std::__cxx11::basic_string, std::allocator > const&)@@GLIBCXX_3.4.21 Is this ok to point to LIBCXX_3.4.21 or should it be GLIBCXX_3.4.25 ? Thanks — eucristian, Jan 25 '19 at 15:45
@eucristian various versions of g++ have different update (my poor English). There is no upgrade for std::string in the later versions of g++, so it still use the old one. What's the problem? — Zhang, Jan 25 '19 at 16:04
@YSC can you please look at the question that you marked as a duplicate with? This question is not about the differences between GCC and G++ but about why is GCC not behaving like i think it should. I do thank you though for the link as it seems really interesting. — eucristian, Jan 25 '19 at 16:07
@Zhang i thought that as well, but just trying to make sure as it is the first time that i am installing gcc without yum. Thank you — eucristian, Jan 25 '19 at 16:08
Just saw your last comment. I cannot remove the dup from my phone. Is there no dup hammer available please? — YSC, Jan 25 '19 at 16:24
ok. can you please remove it when you get home though. And i honestly thank you guys for the link with the differences between gcc and g++. StackOverflow rocks! — eucristian, Jan 25 '19 at 16:40
@eucristian I added a concrete action item question to the end. Please remove if you disagree with its utility, but I find questions with a concrete "this would solve my problem if it was solved" to work better on SO. — Yakk - Adam Nevraumont, Jan 25 '19 at 21:17
Possible duplicate of [What is the difference between g++ and gcc?](https://stackoverflow.com/questions/172587/what-is-the-difference-between-g-and-gcc) — Alan Birtles, Feb 11 '19 at 11:02
@AlanBirtles can you please explain why would this be a duplicate? Thank you — eucristian, Feb 11 '19 at 11:44
You said `g++` works and `gcc` doesn't the answers in the duplicates explain the differences between the two — Alan Birtles, Feb 11 '19 at 11:47
True. But knowing the differences still doesn't explain why it isn't working on GCC (it should work as this is not a difference). — eucristian, Feb 11 '19 at 11:48
If you try to compile c++ code with `gcc` and don't specify all the required flags it isn't surprising that it doesn't work correctly — Alan Birtles, Feb 11 '19 at 16:06
Can you please elaborate on the above statement? What flag am i missing? — eucristian, Feb 11 '19 at 16:30
See the linked post it explains the extra flags that are added when calling `g++` instead of `gcc` — Alan Birtles, Feb 11 '19 at 18:04

GCC not using proper version of std::string

0 Answers0