Centos的6.6分割故障用glibc 2.14

Question

我一直在試圖理解這種情況：

我想在蟒蛇3使用Python包，需要的glibc 2.14。由於Centos 6.x只使用glibc 2.12，我編譯了glibc 2.14並安裝到/opt/glibc-2.14。

我正在安裝Anaconda3。運行測試看起來是這樣的：

用系統默認的glibc它的工作原理：

/opt/anaconda3/bin/python -c "import pandas"

但編譯glibc的

export LD_LIBRARY_PATH=/opt/glibc-2.14/lib/:$LD_LIBRARY_PATH /opt/anaconda3/bin/python -c "import pandas"

它適用於一些機器......我安裝了20多臺虛擬機，並且在某些機器上工作總是有效的，有些機器卻無法工作，我收到：Segmentation fault (core dumped)。在大多數機器上它不起作用。

有沒有人有任何想法爲什麼這種奇怪的情況發生？或者，也許經歷過這樣的問題，

Answer 1

沒有人有任何想法，爲什麼這種奇怪的情況occures

由於this answer解釋，你在做什麼是不應該的工作：你有ld-linux和libc.so.6之間的不匹配。

Answer 2

經過一些更多的調查後，我發現爲實驗室機器分配更多的內存（從2/4 GB到6或更多）會使segmentation fault錯誤消失。但是，32 GB的生產機器仍然存在問題。真奇怪。

現在我發現了一個解決方法，它是來自anaconda的新的python軟件包，與glibc 2.12（幾天前可用）兼容，軟件包的依賴關係也不需要更新的glibc。

@僱用俄語： 謝謝，但可能不是Multiple glibc libraries on a single host的問題。在我的情況下，Python可以使用額外的glibc。問題是segmentation fault顯示在隨機機器上，而只使用新的glibc。此外，我正在使用其他需要glibc 2.14才能工作的Python包，所以我知道我目前使用的是哪個版本的glibc。

此外，如果在圖書館有某種不匹配，那麼它應該根本無法工作（......很可能）。

另外，正如我在開始時提到的，我注意到問題與內存有關（仍然不確定32 GB RAM機器發生了什麼）。

還有一件事：我不編譯python包，所以改變編譯器選項od'myapp'（python包）不是一個選項。

雖然欣賞你的答案。