Linux共享庫文件（.so文件）的疑問

icer_repls

我對Linux的里面的共享庫文件組織方式比較困惑：一個so文件鏈接來鏈接去的目的是什么？這樣做的意義？
舉個例子：

$ file /usr/lib/librt.so
/usr/lib/librt.so: symbolic link to `/lib/librt.so.1'
$ file /lib/librt.so.1
/lib/librt.so.1: symbolic link to `librt-2.11.3.so'
$ file /lib/librt-2.11.3.so
/lib/librt-2.11.3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped

感覺這樣很麻煩~請問這樣設(shè)計的理由是什么？

yanu

當/lib/librt-2.11.3.so 升級為/lib/librt-2.11.4.so的時候，你就知道 /lib/librt.so.1 這個軟連接的好處了

icer_repls

yanu 發(fā)表于 2012-09-23 22:43
當/lib/librt-2.11.3.so 升級為/lib/librt-2.11.4.so的時候，你就知道 /lib/librt.so.1 這個軟連接的好處了 ...

可否舉個例子詳說一下？

我之前遇到過一個案例，想要從jdk1.5升級到1.6，結(jié)果利用aptitude install jdk-1.6之后，發(fā)現(xiàn)java -version還是1.5版本，不起作用，于是我就將那個軟連接自己手動連接到1.6的那個，不知道這算不算一個好處？

yanu

1. # ls -l /lib64/libc.so.6
   
2. lrwxrwxrwx 1 root root 12 May 29 22:25 /lib64/libc.so.6 -> libc-2.15.so
   

復(fù)制代碼

1. # ldd /bin/ls
   
2.         linux-vdso.so.1 (0x00007fff0ddff000)
   
3.         librt.so.1 => /lib64/librt.so.1 (0x00007f8cd1455000)
   
4.         libacl.so.1 => /lib64/libacl.so.1 (0x00007f8cd124c000)
   
5.         libc.so.6 => /lib64/libc.so.6 (0x00007f8cd0ea1000)
   
6.         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8cd0c84000)
   
7.         /lib64/ld-linux-x86-64.so.2 (0x00007f8cd165e000)
   
8.         libattr.so.1 => /lib64/libattr.so.1 (0x00007f8cd0a7f000)
   

復(fù)制代碼

libc-2.15.so是glibc的基礎(chǔ)庫文件，幾乎所有的C程序都要用到這個庫，
如果ls直接引用/lib64/libc-2.15.so，當glibc升級到2.16，這庫文件名字變成/lib64/libc-2.16.so時，ls就會因為找不到/lib64/libc-2.15.so而無法執(zhí)行

如果glibc每個版本的庫文件都使用相同的名字，多個版本又無法共存

icer_repls

回復(fù) 4# yanu

那再請教一個問題：你說：ls就會因為找不到/lib64/libc-2.15.so而無法執(zhí)行，為什么一定非得/lib64/libc-2.15.so這個名稱呢？這個是限制死的？


   

yanu

嗯，庫文件的文件名在編譯的時候?qū)懰涝诙�進制文件里面了

icer_repls

回復(fù) 6# yanu

哦，那這樣做確實有理由。