如何解決依賴性問題？

不管是初步跨入Linux殿堂的新手,還是具有多年經驗的專家，在安裝或編譯軟體包的過程中或多或少的都會遇到包的依賴問題,從而導致安裝過程無法繼續，比如管理員在安裝LAMP時,包需要libgd.so檔案，而這個檔案屬於GD軟體包。但是在安裝GD軟體包時，可能這個軟體包跟其他軟體包又具有依賴關係，又需要安裝其他軟體包才行。這時有的管理員便失去耐心。在遇到這種Linux軟體包依賴關係問題時，該如何解決呢?在談這個具體的措施之前，先跟大家聊聊Linux系統裡的軟體依賴性問題。

　　一、什麼是依賴性

　　程式依賴於程式碼的共用庫，以便它們可以發出系統調用將輸出發送到裝置或開啟檔案等（共用庫存在於許多方面，而不只局限於系統調用）。沒有共用庫，每次程式員開發一個新的程式，每個程式員都需要從頭開始重寫這些基本的系統操作。當編譯器時，程式員將他的代碼連結到這些庫。如果連結是靜態，編譯後的共用庫對象代碼就添加到程式執行檔案中；如果是動態，編譯後的共用庫對象代碼只在運行時需要它時由程式員載入。動態可執行檔依賴於正確的共用庫或共用對象來進行操作。rpm依賴性嘗試在安裝時強制實施動態可執行檔的共用對象需求，以便在以後當程式運行時不會有與動態連結過程有關的任何問題。

　　注意：還有一種類型的依賴性，它基於顯式的條目，rpm通過程式員將該依賴性強加到rpm設定檔中，但目前我們不關心這種類型的依賴性，這種依賴性比較容易解決。這裡將重點放在rpm強制實施的更加複雜的共用對象依賴性。

　　二、動態可執行檔和共用對象

　　動態可執行檔使用最初編譯和連結程式時使用的庫檔案的共用對象名稱來尋找共用對象。它們在少數的幾個標準位置尋找，比如在/lib和/usr/lib目錄及在LD_LIBRARY_PATH環境變數（主要用於指定尋找共用庫，比如我們在安裝Oracle時指定路徑，export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib:/usr/local/lib）指定的目錄中。順便提一下，在這些庫目錄中找到的共用對象可能不是真正的檔案;它們可能是指向位於其他位置的真實庫檔案的符號連結（但通常仍舊在標準庫目錄的一個目錄中）。至少從系統管理員的觀點是在用於建立共用庫檔案的共用庫軟體包的名稱和共用庫檔案的名稱之間通常沒有什麼關係。例如，GLIBC 2.3軟體包用於建立libc.so.6共用庫檔案。也從本樣本中注意到，添加到共用庫檔案名稱結束的版本號碼(.6)跟用於建立它的版本號碼(2.3)沒有關係。這是由共用庫軟體包開發人員有意完成的，以便GLIBC的新版本可以重用相同的共用庫檔案名稱libc.so.6。這允許您在系統上載入新版本的GLIBC，而不用中斷動態連結到lib.so.6共用庫檔案的所有程式，當然假定新版本的GLIBC向後與動態可執行檔最初所連結的老版本GLIBC相容。因此，即使庫檔案或共用對象檔案有與它們相關的版本號碼，這些版本號碼也不能協助你確定他們來自哪個版本的共用軟體包。

　　注意：當將whatprovides選項用於rpm查詢命令時，可以獲得有關使用rpm軟體包載入到系統的現有共用對象的資訊。這種混亂是由下面的事實造成的：單個共用庫檔案可能支援某個範圍的共用庫軟體包版本。例如，要檢查soname庫檔案/lib/libc.so.6支援的GLIBC共用庫軟體包，運行下面的命令：

　　#objdump --all-headers /lib/libc.so.6 | less

　　向下滾動此報告，直到到達Version definitions: 部分，以便查看libc.so.6共用庫檔案支援哪些GLIBC版本：

　　Version definitions:

　　1 0x01 0x0865f4e6 libc.so.6

　　2 0x00 0x0d696910 GLIBC_2.0

　　3 0x00 0x0d696911 GLIBC_2.1

　　GLIBC_2.0

　　4 0x00 0x09691f71 GLIBC_2.1.1

　　GLIBC_2.1

　　5 0x00 0x09691f72 GLIBC_2.1.2

　　GLIBC_2.1.1

　　6 0x00 0x09691f73 GLIBC_2.1.3

　　GLIBC_2.1.2

　　7 0x00 0x0d696912 GLIBC_2.2

　　GLIBC_2.1.3

　　8 0x00 0x09691a71 GLIBC_2.2.1

　　GLIBC_2.2

　　9 0x00 0x09691a72 GLIBC_2.2.2

　　GLIBC_2.2.1

　　10 0x00 0x09691a73 GLIBC_2.2.3

　　GLIBC_2.2.2

　　11 0x00 0x09691a74 GLIBC_2.2.4

　　GLIBC_2.2.3

　　12 0x00 0x09691a76 GLIBC_2.2.6

　　GLIBC_2.2.4

　　13 0x00 0x0d696913 GLIBC_2.3

　　GLIBC_2.2.6

　　14 0x00 0x09691972 GLIBC_2.3.2

　　GLIBC_2.3

　　15 0x00 0x09691973 GLIBC_2.3.3

　　GLIBC_2.3.2

　　16 0x00 0x09691974 GLIBC_2.3.4

　　GLIBC_2.3.3

　　17 0x00 0x0d696914 GLIBC_2.4

　　GLIBC_2.3.4

　　18 0x00 0x0d696915 GLIBC_2.5

　　GLIBC_2.4

　　19 0x00 0x0963cf85 GLIBC_PRIVATE

　　GLIBC_2.5

　　20 0x00 0x0b792650 GCC_3.0

　　在本樣本中，1ibc.so.6共用庫檔案支援原先為GLIBC版本2.0到2.5而開發的所有動態執行檔案。注意：也可以使用objdump命令來從共用庫檔案中提取soname，命令如下所示：

　　# objdump --all -headers /lib/libcrypto.so.0.9.8b| grep SONAME

　　SONAME libcrypto.so.6

　　objdump: /lib/libcrypto.so.0.9.8b: no recognized debugging information

　　接下來，將討論rpm軟體包是如何產生的，以便在新系統上安裝rpm軟體包時，這些共庫依賴性是己知的。
三、Rpm軟體包和共用庫依賴性

　　當程式員產生rpm軟體包時，ldd命令用於報告動態可執行檔軟體包中所有動態可執行檔使用的所有共用庫。另一個混亂是由下面的事實帶來的：相同軟體包中的不同動態可執行檔可能與相同的共用庫軟體包的不同版本進行連結。例如，Heartbeat軟體包中的不同程式可能已經進行了開發，並動態連結到libc.so.6 sonmae共用庫檔案的不同GLIBC版本。對rpm命令使用-q和--requires參數，可以看到rpm軟體包需要的共用庫的完整清單。例如，要看到Heartbeat rpm軟體包所有的所需依賴性，請使用命令：

　　#rpm -q --requires -p heartbeat-1.x.x.i386.rpm

　　這產生了下面的報告：

　　sysklogd

　　/bin/sh

　　/bin/sh

　　/usr/bin/python

　　ld-linux.so.2

　　libapphb.so.0

　　libc.so.6

　　libc.so.6(GLIBC_2.0)

　　libc.so.6(GLIBC_2.1)

　　libc.so.6(GLIBC_2.1.3)

　　libc.so.6(GLIBC_2.2)

　　libc.so.6(GLIBC_2.3)

　　libccmclient.so.0

　　libdl.so.2

　　libglib-1.2.so.0

　　libhbclient.so.0

　　libpils.so.0

　　libplumb.so.0

　　libpthread.so.0

　　librt.so.1

　　libstonith.so.0

　　注意，在此報告中，libc.so.6 soname是所需要的，此共用庫必須支援使用GLIBC共用軟體包版本號碼2.0、2.1、2.1.3、2.2和2.3進行連結的動態可執行檔。這是由下面的事實決定的：Heartbeat軟體包中的不同動態可執行檔是針對不同版本的libc.so.6庫的每個版本進行連結的。在瞭解了動態可執行檔、共用對象、soname和共用庫軟體包彼此是如何相關的後，下面準備來看這樣的一個例子：當嘗試安裝rpm軟體包，並且它由於依賴性錯誤而失敗時，會發生什麼。yum能夠從指定的伺服器自動下載RPM包並且安裝，可以自動處理依賴性關係，並且一次安裝所有依賴的軟體包，無須繁瑣地一次次下載、安裝。

　　四、手工解決依賴性問題

　　通常，當嘗試安裝發行版中沒有包括的軟體包（及不能由像up2date、apt- get或Yum一樣的更新工具自動解決其依賴性的軟體包）時，將碰到rpm依賴性錯誤。例如，如果嘗試在老的Linux發行版上使用rpm –ivh *rpm命令，例如所有的Heartbeat rpm包，那麼在安裝過程中就可能碰到下面的錯誤：

　　error: failed dependencies:

　　libc.so.6(GLIBC_2.3) is needed by heartbeat-1.x.x

　　libc.so.6(GLIBC_2.3) is needed by heartbeat-pils-1.x.x

　　libcrypto.so.0.9.6 is needed by heartbeat-stonith-1.x.x

　　libsnmp-0.4.2.6.so is needed by heartbeat-stonith-1.x.x

　　注意，rpm命令沒有幹擾報告所需的每個GLIBC共用庫軟體包版本號碼——它只報告所需的最高編號的版本號碼(GLIBC_2.3)。(假定原來的軟體包開發人員不會將相同軟體包中的可執行檔連結到不相容版本的共用庫軟體包)所有的這些故障都報告所需的共用庫名稱或soname（而不是檔案名稱，soname始終以“lib”開始）。但可以刪除添加到rpm報告的soname結束的版本號碼，並快速檢查以查看是否在系統中使用locate命令安裝這些共用庫(假設您的locate資料庫是最新的，有關更多資訊，請參閱locate或slocate的手冊頁)。例如，要尋找libcrypto享庫檔案，要輸入：

　　#locate libcrypto

　　[root@localhost ~]# locate libcrypto

　　/lib/libcrypto.so.0.9.8b

　　/lib/libcrypto.so.6

　　/root/.Trash/vmware-tools-distrib/lib/lib32/libcrypto.so.0.9.8

　　/root/.Trash/vmware-tools-distrib/lib/lib32/libcrypto.so.0.9.8/libcrypto.so.0.9.8

　　/root/.Trash/vmware-tools-distrib/lib/lib64/libcrypto.so.0.9.8

　　/root/.Trash/vmware-tools-distrib/lib/lib64/libcrypto.so.0.9.8/libcrypto.so.0.9.8

　　/usr/lib/libcrypto.a

　　/usr/lib/libcrypto.so

　　/usr/lib/pkgconfig/libcrypto.pc

　　/usr/lib/vmware-tools/lib32/libcrypto.so.0.9.8

　　/usr/lib/vmware-tools/lib32/libcrypto.so.0.9.8/libcrypto.so.0.9.8

　　/usr/lib/vmware-tools/lib64/libcrypto.so.0.9.8

　　/usr/lib/vmware-tools/lib64/libcrypto.so.0.9.8/libcrypto.so.0.9.8

　　如果此命令沒有在系統上找到一個libcrypto共用庫檔案，將需要轉到Internet並找出哪個共用庫軟體包包含此共用庫檔案。完成此項工具的一個快速和簡便方式是只要在http://rpmfind.net上將共用庫的名稱輸入到搜尋欄中。如果將文本libcrypto.so輸入到此搜尋貞中，將很快知道此共用庫是由openssl軟體包提供的。



如果老版本的共用庫資料包已經安裝在系統上，可以用如下的命令確認此軟體包含您需要的共用庫檔案：

　　#rpm -q --provides openssl

　　[root@localhost ~]# rpm -q --provides openssl

　　config(openssl) = 0.9.8b-10.el5

　　lib4758cca.so

　　libaep.so

　　libatalla.so

　　libchil.so

　　libcrypto.so.6

　　libcswift.so

　　libgmp.so

　　libnuron.so

　　libssl.so.6

　　libsureware.so

　　libubsec.so

　　openssl = 0.9.8b-10.el5

　　此命令報告此rpm軟體包中提供的所有內容（這包括軟體包提供的共用庫檔案的soname）。注意：如前面指出的，共用庫軟體包版本號碼沒有並且應該沒有與共用庫檔案( soname)版本號碼的任何對應關係。這裡不進行這方面的討論，因為soname符號連結可能指向不同版本的共用庫檔案，這也是在盡量避免在安裝新版本的共用軟體包時中斷現有動態可執行檔的情況下完成的。
五、自動解決依賴性故障

　　當您使用rpm軟體包來產生、升級或添加新的特性到系統時，依賴性故障可能很快變成一場惡夢。只要通過使用您的發行版供應商的升級服務或工具，就可以避免這場惡夢。例如，當選擇要安裝的rpm軟體包時，Red Hat工具up2date自動從Red Hat下載並安裝所有rpm依賴性。下面就點上列出了幾個完成相同事情的支援社區的免費方法：http://www.rpm.org/。下面將只進一步看到這些自動更新工具中的一種：Yum。

　　1．使用Yum來安裝rpm軟體包

　　Yum(Yellow dog Updater，Modified)程式可從下面網址下載：http://yum.baseurl.org/download/3.4/yum-3.4.3.tar.gz

　　在下載了此軟體包後，可以使用下面的命令像任何其他rpm軟體包那樣安裝它：

　　#rpm -ivh yum*

　　您可能需要更新想用於下載您的rpm軟體包的存放庫。有關Fedora的可用Yum存放庫的清單在http://www.fedoratracker.org要切換到不同的存放庫，下載這些檔案中的一個檔案，並將該檔案作為/etc/yum.conf檔案安裝。現在可以用下面的命令告訴Yum報告儲存在Yum存放庫中、可用於安裝所有軟體包：

　　#yum list

　　[root@localhost ~]# yum list |more

　　This system is not registered with RHN.

　　RHN support will be disabled.

　　Loading "security" plugin

　　Loading "rhnplugin" plugin

　　Installed Packages

　　Deployment_Guide-en-US.noarch 5.2-9 installed

　　Deployment_Guide-zh-CN.noarch 5.2-9 installed

　　Deployment_Guide-zh-TW.noarch 5.2-9 installed

　　GConf2.i386 2.14.0-9.el5 installed

　　GConf2-devel.i386 2.14.0-9.el5 installed

　　ImageMagick.i386 6.2.8.0-4.el5_1.1 installed

　　MAKEDEV.i386 3.23-1.2 installed

　　MySQL-python.i386 1.2.1-1 installed

　　NetworkManager.i386 1:0.6.4-8.el5 installed

　　NetworkManager-glib.i386 1:0.6.4-8.el5 installed

　　2.用Yum安裝新的rpm軟體包

　　在本樣本中，將安裝新的GLIBC軟體包。用簡單的命令安裝最新的GLIBC及其所有依賴性：

　　#yum update glibc

　　如果一切正常，Yum程式將自動檢測、下載並安裝最新GLIBC軟體包所需要的所有rpm軟體包（這裡的GLIBC軟體包是為您的發行版而構建的，不一定是可用的最新版GLIBC軟體包(使用發行版所獲批准的GLIBC共用庫軟體包版本號碼或冒險安裝沒有使用正常系統操作所需要的動態可執行檔的GLIBC軟體包版本)。也可以將list參數用於Yum和grep命令來尋找要安裝的軟體包。例如，要尋找名稱中有SNMP的軟體包，請輸入：

　　# yum list |grep snmp

　　此命令返回如下報告：

　　This system is not registered with RHN.

　　RHN support will be disabled.

　　net-snmp.i386 1:5.3.1-24.el5 installed

　　net-snmp-libs.i386 1:5.3.1-24.el5 installed

　　net-snmp-perl.i386 1:5.3.1-24.el5 installed

　　net-snmp-utils.i386 1:5.3.1-24.el5 installed

　　現在可以容易地使用YUM下載並安裝所有這些rpm軟體包。

　　六、關於升級Gilbc的建議

　　Glibc 庫是Linux 底層的運行庫，其效能對於整個系統的運行有重要的意義。Glibc 庫包含了大量函數，其中的函數可大致分成兩類，一類是與作業系統核心溝通的系統調用介面，它們作為功能型函數被調用，提供對Linux 作業系統調用的封裝與預先處理。另外一類為一般的函數對象，它們提供了經常使用的功能的實現，作為工具型函數使用。在實踐中，有不少軟體就是依賴與Glibc版本才能安裝並運行，說白了對於Glibc版本要求是版本高了不行，低了還不成。這些編譯環境中的應用程式也和其它程式一樣必須有啟動並執行環境，我常遇到管理員在生產中給伺服器裝了最新的Linux發行版，結果應用軟體裝不上去，原因是Glibc的版本不對，有的是寫在原發行版glibc上升級有的是降級，結果倒是整個系統的崩潰，實踐經驗告訴我，你只有選擇相應Linux發行版裡對應的glibc,例如我們單位的一個應用軟體時在rhel3.0下開發的，那麼就得要對應的發行版，換了別的就難說了，任何自己升級或降級Glibc來適應應用軟體的做法都是不可取的，問題最後的解決方案是找到了RHEL3裝上就解決了。在表一中，我把幾個linux發行版原配的Glibc版本列出，供大家參考。
點擊圖片查看大圖



Glibc庫與核心功能組件

　　一說明：

　　GCC依賴於glibc

　　binutils依賴於glibc （binutils提供了一系列用來建立、管理和維護二進位目標檔案的工具程式，如彙編（as）、串連（ld）、靜態庫歸檔（ar）、反組譯碼）

　　make依賴於glibc

　　標頭檔是在編譯時間候gcc所需要的，但本身都是一些文字檔，因此沒有需要的運行環境。

　　常用工具依賴於glibc和各種需要用到的動態庫。

　　下表一列出了多個重要Linux發行版的Glibc的情況

　　Linux發行版 Glibc版本

　　Redhat 9 glibc-2.3.2-5

　　Fedora 1 glibc-2.3.2

　　Redhat Enterprise Linux As 3 glibc-2.3.2-95

　　Redhat Enterprise Linux As 4 glibc-2.3.4

　　Red hat Enterprise linux 5 glibc-2.5-24

　　Red hat Enterprise linux 6 glibc-2.9

　　Centos 5.x glibc-2.5

　　Suse Linux Enterprise Server 9 glibc-2.3.2-92

　　Suse Linux enterprise Server 10 glibc-2.4.31.54

　　Suse Linux Enterprise Server 11 glibc-2.9

點擊圖片查看大圖



Linux發行版glibc (32)位

　　下面介紹幾個查詢glibc版本號碼的方法 ：

　　#ls –al /lib/libc*

　　或者是用下面的命令也可以實現

　　#rpm –qp |grep glibc

　　基於debian的系統通過dpkg –l | grep libc6也可以查到，總之一般都在/usr/share/doc目錄下都能看到glibc的相關資訊。

　　七 、小結

　　大部分情況下，在遇到軟體包依賴關係問題的時候，作業系統提供的檔案名稱字與軟體包名字都會有直接的聯絡。有可能檔案的名字就是軟體包的名字。但是有些時候檔案的名字與軟體包的名字會相差甚遠。此時大部分系統管理員可能光憑檔案名稱字無法找到對應的軟體包。此時可以先在系統安裝光碟片裡找，如果找到那時最佳選項，然後就需要藉助筆者上面談到的一些專業網站，去查詢軟體包的名字了。當系統管理員安裝了某個軟體之後，如果存在軟體包之間的依賴關係，則最好能夠拿本子或者通過其他手段記錄下來。以便下次方便實用，注意工作中的積累，相信絕大部分的軟體包依賴關係問題都會迎刃而解。

本文出自 “李晨光原創技術部落格” 部落格，請務必保留此出處http://chenguang.blog.51cto.com/350944/1034095