我一直在開發一個使用g ++ 4.6和g ++ 4.7的程序。我目前正在利用很多C++ 11的特性。使用C++ 11 /近期g ++版本的可移植性（4.7/4.6）
我做了這個決定，認爲我可以將lib和程序一起捆綁在一個子目錄中，並使用LD_LIBRARY_PATH。自那以後，我發現這導致我的程序出現段錯誤。我可能應該早一點對它進行測試。它似乎是捆綁libc.so.6導致它（可能是其他人，但肯定是libc）。
在過去，我已經使用這種技術，它已經不可能安裝庫並且工作正常，但是我從來不需要在程序中包含libc和libstdC++。
是否有解決此問題的方法，或者我將不得不回滾到較舊的C++/libc/libstdC++版本？ （以及隨之而來的代碼更改的噩夢）
我會避免依靠LD_LIBRARY_PATH - 將其用於測試或開發，但不用於生產部署。
代替具有'-Wl,-rpath,$ORIGIN'鏈接到創建DT_RPATH標籤含有$ORIGIN這意味着動態連接器會尋找共享庫在相同的目錄作爲可執行（或例如使用「-Wl，-rpath，$ ORIGIN /../ LIB '看在../lib）
如果您的程序的任何部分是用G ++ 4.7構建的，那麼您需要在運行時使用libstdC++。
但是，如果問題出在libc.so.6上，那不是GCC問題，我的建議是不要嘗試綁定libc ...嘗試替換系統libc可能不是一個好主意。
我會說只使用g ++ 4.6或4.7，但不能同時使用。 另外... ldconfig會試圖讓你的程序運行libc.so的/ lib或/ usr/lib版本，所以如果你有另外一個，我不知道這是如何工作的。所以也許你應該只使用系統libc。
如果有其他人有任何其他的想法，也張貼他們。
你可以隨時用靜態鏈接C++庫，用'-static-libstdC++'... –
我試過這個，但它不起作用。我必須使用需要dlopen的函數（例如getaddrinfo），我也鏈接到gnutls，它似乎使用不能靜態鏈接的庫。由此產生的二進制顯示libstdC++在ldd中動態鏈接。 – goji
如果問題是libc.so.6那麼它與gcc或g ++無關 –