青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

loop_in_codes

低調做技術__歡迎移步我的獨立博客 codemaro.com 微博 kevinlynx

淺析靜態庫鏈接原理

靜態庫的鏈接基本上同鏈接目標文件.obj/.o相同,但也有些不同的地方。本文簡要描述linux下靜態庫在鏈接過程中的一些細節。

靜態庫文件格式

靜態庫遠遠不同于動態庫,不涉及到符號重定位之類的問題。靜態庫本質上只是將一堆目標文件進行打包而已。靜態庫沒有標準,不同的linux下都會有些細微的差別。大致的格式wiki上描述的較清楚:

Global header
-----------------        +-------------------------------
File header 1       ---> | File name
File content 1  |        | File modification timestamp 
-----------------        | Owner ID
File header 2            | Group ID
File content 2           | File mode
-----------------        | File size in bytes
...                      | File magic
                         +-------------------------------

File header很多字段都是以ASCII碼表示,所以可以用文本編輯器打開。

靜態庫本質上就是使用ar命令打包一堆.o文件。我們甚至可以用ar隨意打包一些文件:

$ echo 'hello' > a.txt && echo 'world' > b.txt
$ ar -r test.a a.txt b.txt
$ cat test.a
!<arch>
a.txt/          1410628755  60833 100   100644  6         `
hello
b.txt/          1410628755  60833 100   100644  6         `
world

鏈接過程

鏈接器在鏈接靜態庫時,同鏈接一般的.o基本相似。鏈接過程大致可以歸納下圖:

總結為:

  • 所有傳入鏈接器的.o都會被鏈接進最終的可執行程序;鏈接.o時,會將.o中的global symbolunresolved symbol放入一個臨時表
  • 如果多個.o定義了相同的global symbol,那么就會得到多重定義的鏈接錯誤
  • 如果鏈接結束了,unresolved symbol表不為空,那么就會得到符號未定義的鏈接錯誤
  • .a靜態庫處理本質上就是處理其中的每一個.o,不同的是,如果某個.o中沒有一個符號屬于unresolved symbol表,也就是鏈接器此時懷疑該.o沒有必要,那么其就會被忽略

可以通過一些代碼來展示以上過程。在開發C++程序時,可以利用文件靜態變量會先于main之前執行做一些可能利于程序結構的事情。如果某個.o(包含靜態庫中打包的.o)被鏈接進程序,那么其文件靜態變量就會先于main初始化。

// test.cpp
#include <stdio.h>

class Test {
public:
    Test() {
        printf("Test ctor\n");
    }
};

static Test s_test;

// lib.cpp
#include <stdio.h>

class Lib {
public:
    Lib() {
        printf("Lib ctor\n");
    }
};

static Lib s_lib;

// main.cpp
#include <stdio.h>

int main() {
    printf("main\n");
    return 0;
}

以上代碼main.cpp中未引用任何test.cpp``lib.cpp中的符號:

$ g++ -o test test.o lib.o main.o
$ ./test
Lib ctor
Test ctor
main

生成的可執行程序執行如預期,其鏈接了test.o``lib.o。但是如果把lib.o以靜態庫的形式進行鏈接,情況就不一樣了:為了做對比,基于以上的代碼再加一個文件,及修改main.cpp

// libfn.cpp
int sum(int a, int b) {
    return a + b;
}

// main.cpp
#include <stdio.h>

int main() {
    printf("main\n");
    extern int sum(int, int);
    printf("sum: %d\n", sum(2, 3));
    return 0;
}

libfn.olib.o創建為靜態庫:

$ ar -r libfn.a libfn.o lib.o
$ g++ -o test main.o test.o -lfn -L.
$ ./test
Test ctor
main
sum: 5

因為lib.o沒有被鏈接,導致其文件靜態變量也未得到初始化。

調整鏈接順序,可以進一步檢驗前面的鏈接過程:

# 將libfn.a的鏈接放在main.o前面

$ g++ -o test test.o -lfn main.o  -L.
main.o: In function `main':
main.cpp:(.text+0x19): undefined reference to `sum(int, int)'
collect2: ld returned 1 exit status

這個問題遇到得比較多,也有點讓人覺得莫名其妙。其原因就在于鏈接器在鏈接libfn.a的時候,發現libfn.o依然沒有被之前鏈接的*.o引用到,也就是沒有任何符號在unresolved symbol table,所以libfn.o也被忽略。

一些實踐

在實際開發中還會遇到一些靜態庫相關的問題。

鏈接順序問題

前面的例子已經展示了這個問題。調整庫的鏈接順序可以解決大部分問題,但當靜態庫之間存在環形依賴時,則無法通過調整順序來解決。

-whole-archive

-whole-archive選項告訴鏈接器把靜態庫中的所有.o都進行鏈接,針對以上例子:

$ g++ -o test -L. test.o -Wl,--whole-archive -lfn main.o -Wl,--no-whole-archive
$ ./test
Lib ctor
Test ctor
main
sum: 5

lib.o也被鏈接了進來。-Wl選項告訴gcc將其作為鏈接器參數傳入;之所以在命令行結尾加上--no-whole-archive是為了告訴編譯器不要鏈接gcc默認的庫

可以看出這個方法還是有點暴力了。

–start-group

格式為:

--start-group archives --end-group

位于--start-group --end-group中的所有靜態庫將被反復搜索,而不是默認的只搜索一次,直到不再有新的unresolved symbol產生為止。也就是說,出現在這里的.o如果發現有unresolved symbol,則可能回到之前的靜態庫中繼續搜索。

$ g++ -o test -L. test.o -Wl,--start-group -lfn main.o -Wl,--end-group
$ ./test
Test ctor
main
sum: 5

查看ldd關于該參數的man page還可以一窺鏈接過程的細節:

The specified archives are searched repeatedly until no new undefined references are created. Normally, an archive is searched only once in the order that it is specified on the command line. If a symbol in that archive is needed to resolve an undefined symbol referred to by an object in an archive that appears later on the command line, the linker would not be able to resolve that reference. By grouping the archives, they all be searched repeatedly until all possible references are resolved.

嵌套靜態庫

由于ar創建靜態庫時本質上只是對文件進行打包,所以甚至可以創建一個嵌套的靜態庫,從而測試鏈接器是否會遞歸處理靜態庫中的.o

$ ar -r libfn.a libfn.o
$ ar -r liboutfn.a libfn.a lib.o
$ g++ -o test -L. test.o main.o -loutfn
main.o: In function `main':
main.cpp:(.text+0x19): undefined reference to `sum(int, int)'
collect2: ld returned 1 exit status

可見鏈接器并不會遞歸處理靜態庫中的文件

之所以要提到嵌套靜態庫這個問題,是因為我發現很多時候我們喜歡為一個靜態庫工程鏈接其他靜態庫。當然,這里的鏈接并非真正的鏈接(僅是打包),這個過程當然可以聰明到將其他靜態庫里的.o提取出來然后打包到新的靜態庫。

如果我們使用的是類似scons這種封裝更高的依賴項管理工具,那么它是否會這樣干呢?

基于之前的例子,我們使用scons來創建liboutfn.a

# Sconstruct
StaticLibrary('liboutfn.a', ['libfn.a', 'lib.o'])

使用文本編輯器打開liboutfn.a就可以看到其內容,或者使用:

$ ar -tv liboutfn.a
rw-r--r-- 60833/100   1474 Sep 14 02:59 2014 libfn.a
rw-r--r-- 60833/100   2448 Sep 14 02:16 2014 lib.o

可見scons也只是單純地打包。所以,在scons中構建一個靜態庫時,再鏈接其他靜態庫是沒有意義的

參考文檔

posted on 2014-09-15 22:47 Kevin Lynx 閱讀(4285) 評論(2)  編輯 收藏 引用 所屬分類: c/c++

評論

# re: 淺析靜態庫鏈接原理 2014-09-16 08:52 ccsdu2009

受教了  回復  更多評論   

# re: 淺析靜態庫鏈接原理 2014-09-16 09:24 zuhd

最近干貨很多啊  回復  更多評論   

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            99精品国产高清一区二区| 一本久道综合久久精品| 欧美不卡视频| 久久精品视频va| 久久成人精品一区二区三区| 亚洲午夜免费视频| 亚洲丝袜av一区| 亚洲欧美久久久| 久久精品国产精品| 久色成人在线| 欧美日韩国产成人高清视频| 欧美视频一区二区在线观看| 国产精品国产三级国产专播品爱网| 欧美天天在线| 韩日欧美一区二区| 亚洲精品久久久久久久久| 中文国产一区| 午夜精品久久久久久99热| 欧美在线你懂的| 美女精品在线观看| 亚洲国产精品传媒在线观看 | 在线观看成人小视频| 狠狠色香婷婷久久亚洲精品| 亚洲国产天堂网精品网站| 一区二区日韩精品| 久久精品99久久香蕉国产色戒| 欧美a级在线| 亚洲午夜未删减在线观看| 久久精品综合网| 国产精品video| 亚洲国产欧洲综合997久久| 亚洲欧美在线x视频| 久久免费99精品久久久久久| 欧美韩国日本综合| 亚洲欧美激情一区| 老司机午夜精品视频| 欧美激情视频网站| 国产精品久久久久91| 国产视频观看一区| 在线看片第一页欧美| 99成人在线| 欧美专区在线观看一区| 蜜桃av综合| 一区二区电影免费观看| 久久成人免费视频| 欧美美女bbbb| 国产色综合久久| 99热在这里有精品免费| 午夜精品亚洲一区二区三区嫩草| 久久av一区| 亚洲黄色在线看| 亚洲免费人成在线视频观看| 欧美精品二区| 99热这里只有成人精品国产| 亚洲第一福利视频| 久久久久久夜精品精品免费| 亚洲国产裸拍裸体视频在线观看乱了中文| 欧美jjzz| 久久久精品欧美丰满| 国产精品资源| 午夜一区二区三视频在线观看| 亚洲韩日在线| 欧美大片在线观看一区| 亚洲国产小视频| 欧美国产日韩精品免费观看| 久久久www免费人成黑人精品| 国产三级欧美三级| 久久综合色一综合色88| 久久久久久夜| 亚洲日本视频| 日韩视频国产视频| 欧美午夜精品久久久| 亚洲综合成人在线| 亚洲主播在线| 好吊色欧美一区二区三区四区| 久久美女艺术照精彩视频福利播放| 欧美亚洲日本网站| 在线观看欧美黄色| 亚洲日本中文字幕区| 欧美日韩精品一区二区三区| 亚洲午夜影视影院在线观看| 亚洲视频在线一区| 国产在线成人| 亚洲高清自拍| 欧美日韩三区| 久久大香伊蕉在人线观看热2| 欧美一级视频免费在线观看| 狠狠入ady亚洲精品| 亚洲二区在线视频| 国产精品成人一区二区三区吃奶| 国产精品一区在线观看| 狠狠色狠狠色综合人人| 欧美激情一区二区三区高清视频| 欧美精品aa| 亚洲欧美国产毛片在线| 欧美在线1区| 亚洲日本中文字幕免费在线不卡| 亚洲精品一区中文| 国产一区二区三区精品欧美日韩一区二区三区 | 欧美高清视频一区二区| 一区二区三区精品在线| 亚洲欧美一区二区精品久久久| 影音先锋在线一区| 亚洲视频第一页| 亚洲国产欧美不卡在线观看| 亚洲天堂av高清| 91久久精品一区| 午夜精品短视频| 日韩一级二级三级| 久久一区二区精品| 午夜一区不卡| 欧美另类videos死尸| 久久精品国产亚洲高清剧情介绍| 母乳一区在线观看| 欧美有码视频| 欧美日精品一区视频| 免费在线亚洲| 国产性色一区二区| 一区二区三区欧美视频| 亚洲三级观看| 久久综合九色综合久99| 久久精品国产亚洲精品| 国产精品黄视频| 亚洲日韩欧美视频一区| 亚洲大胆人体视频| 久久精品99国产精品| 欧美一级专区免费大片| 欧美人与性动交a欧美精品| 久久综合国产精品| 国产午夜精品美女视频明星a级| 一本久久知道综合久久| 一区二区三区 在线观看视频| 久久中文在线| 鲁鲁狠狠狠7777一区二区| 国产日韩一区二区三区| 亚洲小视频在线| 香蕉久久精品日日躁夜夜躁| 欧美三级视频| 一区二区三区国产| 亚洲一区二区三区国产| 欧美日韩在线播放一区二区| 99re66热这里只有精品3直播 | 亚洲精品一区二区三区樱花| 久久中文在线| 欧美激情在线免费观看| 亚洲电影免费在线| 免费在线观看成人av| 欧美激情一区二区三区在线视频观看 | 欧美激情在线有限公司| 亚洲国产欧美不卡在线观看| 葵司免费一区二区三区四区五区| 老司机免费视频一区二区| 激情久久影院| 免费不卡中文字幕视频| 91久久精品一区二区别| 亚洲视频1区2区| 国产精品日韩在线播放| 欧美一级大片在线免费观看| 久久伊人免费视频| 亚洲国产一区二区三区青草影视| 免费视频最近日韩| 99精品欧美| 欧美影院精品一区| 亚洲国产精彩中文乱码av在线播放| 免费看亚洲片| 99re成人精品视频| 久久精品在线观看| 亚洲日本中文| 国产精品视频第一区| 久久久亚洲欧洲日产国码αv | 欧美视频不卡| 久久精品亚洲精品| 亚洲美女免费精品视频在线观看| 午夜精品一区二区三区在线视| 国产一区二区在线免费观看| 美脚丝袜一区二区三区在线观看| 亚洲美女性视频| 久久综合久久88| 在线一区二区三区四区五区| 国产日韩欧美视频| 欧美激情1区2区3区| 亚洲欧美中文另类| 亚洲国产天堂久久综合网| 校园春色综合网| 亚洲精选国产| 激情久久综合| 国产伦精品一区二区三区四区免费 | 中日韩男男gay无套| 欧美91视频| 欧美与欧洲交xxxx免费观看 | 国产亚洲精品自拍| 欧美精品18| 久久在线视频| 欧美亚洲一区二区三区| 亚洲免费成人av| 欧美freesex交免费视频| 欧美在线精品免播放器视频| 日韩亚洲欧美在线观看| 在线成人亚洲| 国产日本欧美在线观看|