CXX11與GCC 6.2.0

我們手動科學的Linux機器上安裝了GCC 6.2.0未定義的引用。一個C++應用程序的編譯似乎不錯，但我們在鏈接時CXX11與GCC 6.2.0

file.cpp:(.text+0x16cb): undefined reference to `std::__cxx11::list<void*, std::allocator<void*> >::list(std::__cxx11::list<void*, std::allocator<void*> > const&)'

獲得大量的undefined references到CXX11我們意識到double ABI issue，但與-D_GLIBCXX_USE_CXX11_ABI=0編譯沒什麼區別。我們還有什麼其他選擇？

UPDATE

CMake的配置是如下：

-- The C compiler identification is GNU 6.2.0 
-- The CXX compiler identification is GNU 6.2.0 
-- Check for working C compiler: /opt/GNU/gcc-6.2.0/bin/gcc 
-- Check for working C compiler: /opt/GNU/gcc-6.2.0/bin/gcc -- works 
-- Detecting C compiler ABI info 
-- Detecting C compiler ABI info - done 
-- Check for working CXX compiler: /opt/GNU/gcc-6.2.0/bin/g++ 
-- Check for working CXX compiler: /opt/GNU/gcc-6.2.0/bin/g++ -- works 
-- Detecting CXX compiler ABI info 
-- Detecting CXX compiler ABI info - done

這是file.cpp

gcc-6.2.0/bin/g++ -O3 -fopenmp -DNO_HDF5 -D_GLIBCXX_USE_CXX11_ABI=0 -I./include -I/opt/mpich/3.2/include -o file.cpp.o -c file.cpp

和鏈接（其中它實際上失敗）

編譯行

gcc-6.2.0/bin/g++ -O3 -fopenmp -DNO_HDF5 -D_GLIBCXX_USE_CXX11_ABI=0  main.cpp.o -o ASTEP -rdynamic libMainASTEPlib.a -lhdf5_hl -lhdf5 -lz -lm -lhdf5_hl -lhdf5 -lz -lm /opt/mpich/3.2/lib/libmpicxx.so /opt/mpich/3.2/lib/libmpi.so -Wl,-rpath,/opt/mpich/3.2/lib

此外，MPICH 3.2已建成新的編譯器（GCC 6.2.0）

來源

2016-12-08 Manolete

*您如何鏈接您的程序？用'ld'？用'gcc'？用'g ++'？ –

刪除目標文件並重新編譯。 –

在安裝gcc時，gcc更願意假設它的庫將被安裝到/ usr/lib（64）？中，而不管你真的在哪裏推送gcc。因此，您的代碼最終會與系統的標準庫鏈接。不幸的是，我忘記了如何從gcc的配置中剔除糟糕的細節，以便正確設置它以便與安裝它們的庫鏈接。你必須弄清楚，就像我在10年前做的那樣......如果我記得所有這些，我會發佈一個答案。 –

我不明白爲什麼你的對象仍然有std::__cxx11::list引用，當你用-D_GLIBCXX_USE_CXX11ABI=0編譯，除非宏則是在頭文件/源文件中重新定義。您應該確保file.o對象正確地放入任何存檔應該包含它（並且任何舊版本肯定已經消失）。隨着中說：

您可能需要對鏈接的libstdc自帶的GCC 6.2.0，不與貌似對應到一個較早的編譯器，庫的系統版本++庫。

這可能需要使用-nostdlib然後手動添加-L/(path)/gcc-6.2.0/lib -lstdc++ -lc或相似。

或者，也可以是能夠使用系統C++頭文件，而不是在gcc 6.2.0頭進行編譯。那麼你也應該能夠成功地鏈接到系統的libstdC++庫。在這種情況下，您需要-nostdinc++，然後-I/usr/include/c++/5（例如）。請注意，在這種情況下，-D_GLIBCXX_USE_CXX11_ABI=0將不起作用且不必要;舊圖書館沒有雙ABI。

來源

2016-12-08 14:11:14 davmac

'gcc'在自己的安裝中搜索'libstdC++'，而不是在系統位置（我總是將gcc安裝到非標準的位置）。 –

@ n.m。然而，在這種情況下顯然不這樣做。 – davmac

事實是，gcc默認是這樣做的。在這種情況下，我們對一些未知的現象有一些間接的觀察。從這裏到明確建立任何東西都是漫長的道路。直到最詳細的構建日誌發佈爲止。 –

回答

相關問題