When trying to use the current GCC to use some new / experimental materials in C ++, I encountered a binding error. It seems like a similar question has already been posted, but still getting the error.
Can someone explain to me what / where I did wrong here ?. Hope I have provided all the detailed information related to this.
test.cpp
#include<iostream> #include<string> #include<experimental/filesystem> namespace fs = std::experimental::filesystem; int main(int argc, const char* argv[]) { std::string s(argv[0]); fs::path p(s); std::cout << "p = " << p << std::endl; return 0; }
I built ( debug version ) the new gcc version 6.0.0 20151122 (experimental) (GCC) as g ++ - 6.0.0. Here I use the new option -lstdC ++ fs, which is required for FS TS. I can use other new things such as C ++ Concept .
~/practice/gcc6$ g++-6.0.0 -v -g -lstdc++fs -o out test.cpp Using built-in specs. COLLECT_GCC=g++-6.0.0 COLLECT_LTO_WRAPPER=/usr/gcc_6_0/libexec/gcc/x86_64-linux-gnu/6.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../configure --build=x86_64-linux-gnu --prefix=/usr/gcc_6_0 --with-gmp=/usr/gcc_6_0 --with-mpfr=/usr/gcc_6_0 --with-mpc=/usr/gcc_6_0 --enable-languages=c,c++,fortran --disable-multilib --program-suffix=-6.0.0 Thread model: posix gcc version 6.0.0 20151122 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-g' '-o' 'out' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/gcc_6_0/libexec/gcc/x86_64-linux-gnu/6.0.0/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -g -version -o /tmp/ccX3oTv2.s GNU C++ (GCC) version 6.0.0 20151122 (experimental) (x86_64-linux-gnu) compiled by GNU C version 6.0.0 20151122 (experimental), GMP version 6.1.0, MPFR version 3.1.3, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/../../../../include/c++/6.0.0 /usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/../../../../include/c++/6.0.0/x86_64-linux-gnu /usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/../../../../include/c++/6.0.0/backward /usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/include /usr/local/include /usr/gcc_6_0/include /usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++14 (GCC) version 6.0.0 20151122 (experimental) (x86_64-linux-gnu) compiled by GNU C version 6.0.0 20151122 (experimental), GMP version 6.1.0, MPFR version 3.1.3, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 14452760b2e0f1df03cbd137364317c8 COLLECT_GCC_OPTIONS='-v' '-g' '-o' 'out' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o /tmp/ccMWw2R6.o /tmp/ccX3oTv2.s GNU assembler version 2.25.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.25.1 COMPILER_PATH=/usr/gcc_6_0/libexec/gcc/x86_64-linux-gnu/6.0.0/:/usr/gcc_6_0/libexec/gcc/x86_64-linux-gnu/6.0.0/:/usr/gcc_6_0/libexec/gcc/x86_64-linux-gnu/:/usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/:/usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/:/usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-g' '-o' 'out' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/gcc_6_0/libexec/gcc/x86_64-linux-gnu/6.0.0/collect2 -plugin /usr/gcc_6_0/libexec/gcc/x86_64-linux-gnu/6.0.0/liblto_plugin.so -plugin-opt=/usr/gcc_6_0/libexec/gcc/x86_64-linux-gnu/6.0.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccQOTKmb.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o out /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/crtbegin.o -L/usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0 -L/usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/../../.. -lstdc++fs /tmp/ccMWw2R6.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/gcc_6_0/lib/gcc/x86_64-linux-gnu/6.0.0/crtend.o /usr/lib/x86_64-linux-gnu/crtn.o /tmp/ccMWw2R6.o: In function `std::experimental::filesystem::v1::__cxx11::path::path<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::experimental::filesystem::v1::__cxx11::path>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)': /usr/gcc_6_0/include/c++/6.0.0/experimental/bits/fs_path.h:167: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()' collect2: error: ld returned 1 exit status
Below is the details of the version of GCC installed on the machine.
~/practice/gcc6$ g++-6.0.0 -v Using built-in specs. COLLECT_GCC=g++-6.0.0 COLLECT_LTO_WRAPPER=/usr/gcc_6_0/libexec/gcc/x86_64-linux-gnu/6.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../configure --build=x86_64-linux-gnu --prefix=/usr/gcc_6_0 --with-gmp=/usr/gcc_6_0 --with-mpfr=/usr/gcc_6_0 --with-mpc=/usr/gcc_6_0 --enable-languages=c,c++,fortran --disable-multilib --program-suffix=-6.0.0 Thread model: posix gcc version 6.0.0 20151122 (experimental) (GCC)
Tried to extract libstdc ++ fs.a. From the commands below, I could see that the method below exists in the dir.o object file. However, the linker still throws the undefined reference error.
~/practice/gcc6$ ar t /usr/gcc_6_0/lib64/libstdc++fs.a dir.o ops.o path.o cow-dir.o cow-ops.o cow-path.o ~/practice/gcc6$ nm dir.o |grep "split" U _ZNSt12experimental10filesystem2v17__cxx114path14_M_split_cmptsEv ~/practice/gcc6$ nm dir.o |c++filt |grep "split" U std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts(
)
It seems that the path is also set correctly.
~/practice/gcc6$ which g++-6.0.0 /usr/gcc_6_o/bin/g++-6.0.0
This is a debug version.
~/practice/gcc6$ file /usr/gcc_6_0/bin/g++-6.0.0 /usr/gcc_6_0/bin/g++-6.0.0: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped
Update
Putting - lstd ++ fs at the end of the command works fine, as Galik suggested in the comment. However, I would like to know how you determined that the command used by me is incorrect?
From all my analysis, I was not able to identify the key to the GCC, which could indicate this. It would be great if someone could provide some details on ordering a new linker option (-lstdC ++ fs). There is no information on ordering this linker option in the GCC documentation.