Linux程序編譯鏈接動態庫版本的問題

不同版本的動態庫可能會不兼容，如果程序在編譯時指定動態庫是某個低版本，運行是用的一個高版本，可能會導致無法運行。Linux上對動態庫的命名採用libxxx.so.a.b.c的格式，其中a代表大版本號，b代表小版本號，c代表更小的版本號，我們以Linux自帶的cp程序爲例，通過ldd查看其依賴的動態庫

 $ ldd /bin/cp                                                                                                                                                                                        
linux-vdso.so.1 =>  (0x00007ffff59df000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fb3357e0000)
librt.so.1 => /lib64/librt.so.1 (0x00007fb3355d7000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007fb3353cf000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007fb3351ca000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb334e35000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb334c31000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb335a0d000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb334a14000)

左邊是依賴的動態庫名字，右邊是鏈接指向的文件，再查看libacl.so相關的動態庫

  $ ll /lib64/libacl.so*                                                                                                                                                                               
lrwxrwxrwx. 1 root root    15 1月   7 2015 /lib64/libacl.so.1 -> libacl.so.1.1.0
-rwxr-xr-x. 1 root root 31280 12月  8 2011 /lib64/libacl.so.1.1.0

我們發現libacl.so.1實際上是一個軟鏈接，它指向的文件是libacl.so.1.1.0，命名方式符合我們上面的描述。也有不按這種方式命名的，比如

$ ll /lib64/libc.so*                                                                                                                                                                                  
lrwxrwxrwx 1 root root 12 8月  12 14:18 /lib64/libc.so.6 -> libc-2.12.so

不管怎樣命名，只要按照規定的方式來生成和使用動態庫，就不會有問題。而且我們往往是在機器A上編譯程序，在機器B上運行程序，編譯和運行的環境其實是有略微不同的。下面就說說動態庫在生成和使用過程中的一些問題。

動態庫的編譯

我們以一個簡單的程序作爲例子

// filename:hello.c
#include <stdio.h>

void hello(const char* name)
{
    printf("hello %s!\n", name);
}

// filename:hello.h
void hello(const char* name);

採用如下命令進行編譯

gcc hello.c -fPIC -shared -Wl,-soname,libhello.so.0 -o libhello.so.0.0.1

需要注意的參數是 -Wl,soname（中間沒有空格），-Wl選項告訴編譯器將後面的參數傳遞給鏈接器，
-soname則指定了動態庫的soname(簡單共享名，Short for shared object name)

現在我們生成了libhello.so.0.0.1，當我們運行 ldconfig -n . 命令時，當前目錄會多一個軟連接

 $ ll libhello.so.0                                                                                                                                                                                   
lrwxrwxrwx 1 handy handy 17 8月  17 14:18 libhello.so.0 -> libhello.so.0.0.1

這個軟鏈接是如何生成的呢，並不是截取libhello.so.0.0.1名字的前面部分，而是根據libhello.so.0.0.1編譯時指定的-soname生成的。也就是說我們在編譯動態庫時通過-soname指定的名字，已經記載到了動態庫的二進制數據裏面。不管程序是否按libxxx.so.a.b.c格式命名，但Linux上幾乎所有動態庫在編譯時都指定了-soname，我們可以通過readelf工具查看soname，比如文章開頭列舉的兩個動態庫

 $ readelf -d /lib64/libacl.so.1.1.0                                                                                                                                                                   

Dynamic section at offset 0x6de8 contains 24 entries:
Tag        Type                         Name/Value
0x0000000000000001 (NEEDED)             Shared library: [libattr.so.1]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
0x000000000000000e (SONAME)             Library soname: [libacl.so.1]

這裏省略了一部分，可以看到最後一行SONAME爲libacl.so.1，所以/lib64纔會有一個這樣的軟連接

再看libc-2.12.so文件，該文件並沒有採用我們說的命名方式

 $ readelf -d /lib64/libc-2.12.so                                                                                                                                                                      

Dynamic section at offset 0x18db40 contains 27 entries:
Tag        Type                         Name/Value
0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
0x000000000000000e (SONAME)             Library soname: [libc.so.6]

同樣可以看到最後一行SONAME爲libc.so.6，即便該動態庫沒有按版本號的方式命名，但仍舊有一個軟鏈指向該動態庫，而該軟鏈的名字就是soname指定的名字

所以關鍵就是這個soname，它相當於一箇中間者，當我們的動態庫只是升級一個小版本時，我們可以讓它的soname相同，而可執行程序只認soname指定的動態庫，這樣依賴這個動態庫的可執行程序不需重新編譯就能使用新版動態庫的特性

可執行程序的編譯

還是以hello動態庫爲例，我們寫一個簡單的程序

// filename:main.c
#include "hello.h"

int main()
{
    hello("handy");
    return 0;
}

現在目錄下是如下結構

├── hello.c
├── hello.h
├── libhello.so.0 -> libhello.so.0.0.1
├── libhello.so.0.0.1
└── main.c

libhello.so.0.0.1是我們編譯生成的動態庫，libhello.so.0是通過ldconfig生成的鏈接，採用如下命令編譯main.c

 $ gcc main.c -L. -lhello -o main                                                                                                                                                                            
/usr/bin/ld: cannot find -lhello

報錯找不到hello動態庫，在Linux下，編譯時指定-lhello，鏈接器會去尋找libhello.so這樣的文件，當前目錄下沒有這個文件，所以報錯。建立這樣一個軟鏈，目錄結構如下

├── hello.c
├── hello.h
├── libhello.so -> libhello.so.0.0.1
├── libhello.so.0 -> libhello.so.0.0.1
├── libhello.so.0.0.1
└── main.c

讓libhello.so鏈接指向實際的動態庫文件libhello.so.0.0.1，再編譯main程序

gcc main.c -L. -lhello -o main

這樣可執行文件就生成了。通過以上測試我們發現，在編譯可執行程序時，鏈接器會去找它依賴的libxxx.so這樣的文件，因此必須保證libxxx.so的存在

用ldd查看其依賴的動態庫

 $ ldd main                                                                                                                                                                                            
        linux-vdso.so.1 =>  (0x00007fffe23f2000)
        libhello.so.0 => not found
        libc.so.6 => /lib64/libc.so.6 (0x00007fb6cd084000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb6cd427000)

我們發現main程序依賴的動態庫名字是libhello.so.0，既不是libhello.so也不是libhello.so.0.0.1。其實在生成main程序的過程有如下幾步

鏈接器通過編譯命令 -L. -lhello 在當前目錄查找libhello.so文件
讀取libhello.so鏈接指向的實際文件，這裏是libhello.so.0.0.1
讀取libhello.so.0.0.1中的SONAME，這裏是libhello.so.0
將libhello.so.0記錄到main程序的二進制數據裏
也就是說libhello.so.0是已經存儲到main程序的二進制數據裏的，不管這個程序在哪裏，通過ldd查看它依賴的動態庫都是libhello.so.0

而爲什麼這裏ldd查看main顯示libhello.so.0爲not found呢，因爲ldd是從環境變量$LD_LIBRARY_PATH指定的路徑裏來查找文件的，我們指定環境變量再運行如下

 $ export LD_LIBRARY_PATH=. && ldd main                                                                                                                                                                
    linux-vdso.so.1 =>  (0x00007fff7bb63000)
    libhello.so.0 => ./libhello.so.0 (0x00007f2a3fd39000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f2a3f997000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2a3ff3b000)

可執行程序的運行

現在測試目錄結果如下

├── hello.c
├── hello.h
├── libhello.so -> libhello.so.0.0.1
├── libhello.so.0 -> libhello.so.0.0.1
├── libhello.so.0.0.1
├── main
└── main.c

這裏我們把編譯環境和運行環境混在一起了，不過沒關係，只要我們知道其中原理，就可以將其理清楚

前面我們已經通過ldd查看了main程序依賴的動態庫，並且指定了LD_LIBRARY_PATH變量，現在就可以直接運行了

 $ ./main                                                                                                                                                                                              
hello Handy!

看起來很順利。那麼如果我們要部署運行環境，該怎麼部署呢。顯然，源代碼是不需要的，我們只需要動態庫和可執行程序。這裏新建一個運行目錄，並拷貝相關文件，目錄結構如下

├── libhello.so.0.0.1
└── main

這時運行會main會發現

 $ ./main                                                                                                                                                                                              
./main: error while loading shared libraries: libhello.so.0: cannot open shared object file: No such file or directory

報錯說libhello.so.0文件找不到，也就是說 程序運行時需要尋找的動態庫文件名其實是動態庫編譯時指定的SONAME，這也和我們用ldd查看的一致。通過 ldconfig -n . 建立鏈接，如下

├── libhello.so.0 -> libhello.so.0.0.1
├── libhello.so.0.0.1
└── main

再運行程序，結果就會符合預期了

從上面的測試看出，程序在運行時並不需要知道libxxx.so，而是需要程序本身記載的該動態庫的SONAME，所以main程序的運行環境只需要以上三個文件即可

動態庫版本更新

假設動態庫需要做一個小小的改動，如下

// filename:hello.c
#include <stdio.h>

void hello(const char* name)
{
    printf("hello %s, welcom to our world!\n", name);
}

由於改動較小，我們編譯動態庫時仍然指定相同的soname

gcc hello.c -fPIC -shared -Wl,-soname,libhello.so.0 -o libhello.so.0.0.2

將新的動態庫拷貝到運行目錄，此時運行目錄結構如下

├── libhello.so.0 -> libhello.so.0.0.1
├── libhello.so.0.0.1
├── libhello.so.0.0.2
└── main

此時目錄下有兩個版本的動態庫，但libhello.so.0指向的是老本版，運行 ==ldconfig -n .==後我們發現，鏈接指向了新版本，如下

├── libhello.so.0 -> libhello.so.0.0.2
├── libhello.so.0.0.1
├── libhello.so.0.0.2
└── main

再運行程序

 $ ./main                                                                                                                                                                                              
hello Handy, welcom to our world!

沒有重新編譯就使用上了新的動態庫， wonderful！

同樣，假如我們的動態庫有大的改動，編譯動態庫時指定了新的soname，如下

gcc hello.c -fPIC -shared -Wl,-soname,libhello.so.1 -o libhello.so.1.0.0

將動態庫文件拷貝到運行目錄，並執行 ldconfig -n .，目錄結構如下

├── libhello.so.0 -> libhello.so.0.0.2
├── libhello.so.0.0.1
├── libhello.so.0.0.2
├── libhello.so.1 -> libhello.so.1.0.0
├── libhello.so.1.0.0
└── main

這時候發現，生成了新的鏈接libhello.so.1，而main程序還是使用的libhello.so.0，所以無法使用新版動態庫的功能，需要重新編譯才行

最後

在實際生產環境中，程序的編譯和運行往往是分開的，但只要搞清楚這一系列過程中的原理，就不怕被動態庫的版本搞暈。簡單來說，按如下方式來做

編譯動態庫時指定-Wl,-soname,libxxx.so.a，設置soname爲libxxx.so.a，生成實際的動態庫文件libxxx.so.a.b.c
編譯可執行程序時保證libxx.so存在，如果是軟鏈，必須指向實際的動態庫文件libxxx.so.a.b.c
運行可執行文件時保證libxxx.so.a.b.c文件存在，通過ldconfig生成libxxx.so.a鏈接指向libxxx.so.a.b.c
設置環境變量LD_LIBRARY_PATH，運行可執行程序

Linux程序編譯鏈接動態庫版本的問題

動態庫的編譯

可執行程序的編譯

可執行程序的運行

動態庫版本更新

最後

字節跳動-抖音C++開發面經(牛客上的面經，找了答案記錄下來)

讀書筆記（十）－內核同步方法

讀書筆記（七）－中斷處理

讀書筆記（八）－中斷下半部的處理

讀書筆記（十二）－內存管理

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結