1. 程式人生 > >gcc編譯工具生成動態庫和靜態庫

gcc編譯工具生成動態庫和靜態庫

來自:http://www.cnblogs.com/fnlingnzb-learner/ 

1.庫的分類

根據連結時期的不同,庫又有靜態庫和動態庫之分。

靜態庫是在連結階段被連結的(好像是廢話,但事實就是這樣),所以生成的可執行檔案就不受庫的影響了,即使庫被刪除了,程式依然可以成功執行。

有別於靜態庫,動態庫的連結是在程式執行的時候被連結的。所以,即使程式編譯完,庫仍須保留在系統上,以供程式執行時呼叫。(TODO:連結動態庫時連結階段到底做了什麼)

2 靜態庫和動態庫的比較

連結靜態庫其實從某種意義上來說也是一種貼上複製,只不過它操作的物件是目的碼而不是原始碼而已。因為靜態庫被連結後庫就直接嵌入可執行檔案中了,這樣就帶來了兩個問題。

首先就是系統空間被浪費了。這是顯而易見的,想象一下,如果多個程式連結了同一個庫,則每一個生成的可執行檔案就都會有一個庫的副本,必然會浪費系統空間。

再者,人非聖賢,即使是精心除錯的庫,也難免會有錯。一旦發現了庫中有bug,挽救起來就比較麻煩了。必須一一把連結該庫的程式找出來,然後重新編譯。

而動態庫的出現正彌補了靜態庫的以上弊端。因為動態庫是在程式執行時被連結的,所以磁碟上只須保留一份副本,因此節約了磁碟空間。如果發現了bug或要升級也很簡單,只要用新的庫把原來的替換掉就行了。

那麼,是不是靜態庫就一無是處了呢?

答曰:非也非也。不是有句話麼:存在即是合理。靜態庫既然沒有湮沒在滔滔的歷史長河中,就必然有它的用武之地。想象一下這樣的情況:如果你用libpcap庫編了一個程式,要給被人執行,而他的系統上沒有裝pcap庫,該怎麼解決呢?最簡單的辦法就是編譯該程式時把所有要連結的庫都連結它們的靜態庫,這樣,就可以在別人的系統上直接執行該程式了。

所謂有得必有失,正因為動態庫在程式執行時被連結,故程式的執行速度和連結靜態庫的版本相比必然會打折扣。然而瑕不掩瑜,動態庫的不足相對於它帶來的好處在現今硬體下簡直是微不足道的,所以連結程式在連結時一般是優先連結動態庫的,除非用-static引數指定連結靜態庫。

gcc作為編譯工具,用在Linux作業系統中,可以編譯C、C++、Object-C、JAVA等語言。編譯過程中可以帶編譯選項,選擇編譯過程。一、GCC編譯流程1)預處理 Pre-Processing
2)編譯 Compiling
3)彙編 Assembling
4)連結 Linking二、GCC編譯選項


1、gcc總體選項列表


1) -c :指編譯,不連結,生成目標檔案“.o”。
2) -S :只編譯,不彙編,生成彙編程式碼“.S”。
3) -E :只進行預編譯/預處理,不做其他處理。
4) -o file:把輸出檔案輸出到file裡。
5) -g :在可執行程式中包含標準除錯資訊。
6) -v :打印出編譯器內部編譯各過程的命令列資訊和編譯器的版本。
7) -I dir :在標頭檔案的搜尋路徑列表中新增dir目錄
8) -L dir :在庫檔案的搜尋路徑列表中新增dir目錄
9) -static :連線靜態庫(靜態庫也可以用動態庫連結方式連結)
10) -llibrary :連線名為library的庫檔案(顯示指定需要連結的動態庫檔案)


2、gcc告警和出錯選項
1) -ansi :支援符合ANSI標準的C程式
2) -pedantic :允許發出ANSI C標準所列出的全部警告資訊
3) -pedantic-error :允許發出ANSI C標準所列出的全部錯誤資訊
4) -w :關閉所有警告
5) -Wall :允許發出gcc提供的所有有用的報警資訊
6) -werror :把所有的告警資訊轉化為錯誤資訊,並在告警發生時終止編譯過程


3、gcc優化選項
gcc可以對程式碼進行優化,它通過編譯選項“-On”來控制優化程式碼的生成,其中n是一個代表優化級別的整數。對於不同版本的gcc,
n的取值範圍不一致,比較典型的範圍為0變化到2或者3。
雖然優化選項可以加速程式碼的執行速度,但對於除錯而言將是一個很大的挑戰。因為程式碼在經過優化之後,原先在源程式中宣告和使用
的變數很可能不再使用,控制流也可能會突然跳轉到意外的地方,迴圈語句也可能因為迴圈展開而變得到處都有。三、GCC生成動態庫和靜態庫
1)動態庫生成
1.單個原始檔/目標直接生成動態庫
a. 
gcc -fPIC -shared xxx.c -o libxxx.so
b.
gcc -fPIC -shared xxx.o -o libxxx.so

2.多個原始檔/目標生成動態庫

a.
gcc -fPIC -shared xxx1.c xxx2.c xxx3.c -o libxxx.so 
b.
gcc -fPIC -shared xxx1.o xxx2.o xxx3.o -o libxxx.so 

2)靜態庫生成
1.單個原始檔/目標直接生成靜態庫

a.
ar -rc libxxx.a xxx.o(正確方法)
b. ar -rc libxxx.a xxx.c  (靜態庫可以生成;當執行連線了該靜態庫的可執行程式會報錯:could not read symbols:Archive has no index;run ranlib
 to add one)

2.多個原始檔/目標生成靜態庫

a.
ar -rc libxxx.a xxx1.o xxx2.o xxx3.o (正確方法)
b.
ar -rc libxxx.a xxx1.c xxx2.c xxx3.c (靜態庫可以生成;當執行連線了該靜態庫的可執行程式會報錯:could not read symbols:Archive has no index;run ranlib to add one)

四、多個原始檔生成一個可執行檔案

gcc xxx1.c xxx2.c xxx3.c xxx4.c main.c -o main

例項

一、動態連結庫

1.建立hello.so動態庫

  1. #include <stdio.h>  
  2. void hello(){  
  3.     printf("hello world\n");  
  4. }  
  5. 編譯:gcc -fPIC -shared hello.c -o libhello.so  


2.hello.h標頭檔案

  1. void hello();  


3.連結動態庫

  1. #include <stdio.h>  
  2. #include "hello.h"  
  3. int main(){  
  4.     printf("call hello()");  
  5.     hello();  
  6. }  
  7. 編譯:gcc main.c -L. -lhello -o main  

這裡-L的選項是指定編譯器在搜尋動態庫時搜尋的路徑,告訴編譯器hello庫的位置。"."意思是當前路徑.

3.編譯成夠後執行./main,會提示:

  1. In function `main':  
  2. main.c:(.text+0x1d): undefined reference to `hello'  
  3. collect2: ld returned 1 exit status  

這是因為在連結hello動態庫時,編譯器沒有找到。
解決方法:

  1. sudo cp libhello.so /usr/lib/  

這樣,再次執行就成功輸入:
call hello()

二、靜態庫

檔案有:main.c、hello.c、hello.h
1.編譯靜態庫hello.o: 

  1. gcc hello.c -o hello.o  #這裡沒有使用-shared  


2.把目標文件歸檔

  1. ar -r libhello.a hello.o  #這裡的ar相當於tar的作用,將多個目標打包。  

程式ar配合引數-r建立一個新庫libhello.a,並將命令列中列出的檔案打包入其中。這種方法,如果libhello.a已經存在,將會覆蓋現在檔案,否則將新建立。

3.連結靜態庫

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

這裡的-static選項是告訴編譯器,hello是靜態庫。
或者:

  1. gcc main.c libhello.a -L. -o main  

這樣就可以不用加-static

4.執行./main

輸出:call hello()

makefile例項

1. 靜態庫的生成

複製程式碼
# 1、準備工作,編譯方式、目標檔名、依賴庫路徑的定義。
CC = g++
CFLAGS  := -Wall -O3 -std=c++0x 

# opencv 標頭檔案和lib路徑 
OPENCV_INC_ROOT = /usr/local/include/opencv 
OPENCV_LIB_ROOT = /usr/local/lib

OBJS = GenDll.o #.o檔案與.cpp檔案同名
LIB = libgendll.a # 目標檔名 

OPENCV_INC= -I $(OPENCV_INC_ROOT)

INCLUDE_PATH = $(OPENCV_INC)

LIB_PATH = -L $(OPENCV_LIB_ROOT)

# 依賴的lib名稱
OPENCV_LIB = -lopencv_objdetect -lopencv_core -lopencv_highgui -lopencv_imgproc

all : $(LIB)

# 2. 生成.o檔案 
%.o : %.cpp
    $(CC) $(CFLAGS) -c $< -o [email protected] $(INCLUDE_PATH) $(LIB_PATH) $(OPENCV_LIB) 

# 3. 生成靜態庫檔案
$(LIB) : $(OBJS)
    rm -f [email protected]
    ar cr [email protected] $(OBJS)
    rm -f $(OBJS)

tags :
     ctags -R *

# 4. 刪除中間過程生成的檔案 
clean:
    rm -f $(OBJS) $(TARGET) $(LIB)
複製程式碼

2. 動態庫的生成

第1、4步準備和收尾工作與靜態庫的保持一致,第2步和第3步所使用的命令稍有不同。

複製程式碼
# 1、準備工作,編譯方式、目標檔名、依賴庫路徑的定義。
CC = g++
CFLAGS  := -Wall -O3 -std=c++0x 

# opencv 標頭檔案和lib路徑 
OPENCV_INC_ROOT = /usr/local/include/opencv 
OPENCV_LIB_ROOT = /usr/local/lib

OBJS = GenDll.o #.o檔案與.cpp檔案同名
LIB = libgendll.so # 目標檔名 

OPENCV_INC= -I $(OPENCV_INC_ROOT)

INCLUDE_PATH = $(OPENCV_INC)

LIB_PATH = -L $(OPENCV_LIB_ROOT)

# 依賴的lib名稱
OPENCV_LIB = -lopencv_objdetect -lopencv_core -lopencv_highgui -lopencv_imgproc

all : $(LIB)

# 2. 生成.o檔案 
%.o : %.cpp
    $(CC) $(CFLAGS) -fpic -c $< -o [email protected] $(INCLUDE_PATH) $(LIB_PATH) $(OPENCV_LIB) 

# 3. 生成動態庫檔案
$(LIB) : $(OBJS)
    rm -f [email protected]
    g++ -shared -o [email protected] $(OBJS)
    rm -f $(OBJS)

tags :
     ctags -R *

# 4. 刪除中間過程生成的檔案 
clean:
    rm -f $(OBJS) $(TARGET) $(LIB)
複製程式碼

-fpic 和 -shared 命令可參考:Linux下動態庫(.so)和靜態庫(.a)【注】這篇文章說可以使用ld命令生成.so檔案,但我在測試時發會報錯。

3. 動態庫和靜態庫的呼叫

, 這兩個的使用方法幾乎沒有區別。動態庫的引用有顯式和隱式兩種,這裡只說隱式呼叫。我使用main.cpp來測試生成的庫檔案, makefile如下:

複製程式碼
CC = g++
CFLAGS  := -Wall -O3 -std=c++0x 

OPENCV_INC_ROOT = /usr/local/include/opencv 
OPENCV_LIB_ROOT = /usr/local/lib
MY_ROOT = ../

OPENCV_INC= -I $(OPENCV_INC_ROOT)
MY_INC = -I $(MY_ROOT)

EXT_INC = $(OPENCV_INC) $(MY_INC)

OPENCV_LIB_PATH = -L $(OPENCV_LIB_ROOT)
MY_LIB_PATH = -L $(MY_ROOT)

EXT_LIB = $(OPENCV_LIB_PATH) $(MY_LIB_PATH) 

OPENCV_LIB_NAME = -lopencv_objdetect -lopencv_highgui -lopencv_imgproc -lopencv_core 
MY_LIB_NAME = -lgendll

all:test

test:main.cpp
    $(CC) $(CFLAGS) main.cpp $(EXT_INC) $(EXT_LIB) $(MY_LIB_NAME) $(OPENCV_LIB_NAME) -o test
複製程式碼

4. 注意事項:

1、在測試過程中,經常會報錯:找不到.so檔案。一種簡單的解決方法如下: 
在linux終端輸入如下命令:

export LD_LIBRARY_PATH=/home/shaoxiaohu/lib:LD_LIBRARY_PATH:

相關推薦

gcc編譯工具生成動態靜態之一----介紹

 1.庫的分類 根據連結時期的不同,庫又有靜態庫和動態庫之分。 靜態庫是在連結階段被連結的(好像是廢話,但事實就是這樣),所以生成的可執行檔案就不受庫的影響了,即使庫被刪除了,程式依然可以成功執行。 有別於靜態庫,動態庫的連結是在程式執行的時候被連結的。所以,即使程式編譯完,庫仍須保留在系統上

gcc編譯工具生成動態靜態

來自:http://www.cnblogs.com/fnlingnzb-learner/ 1.庫的分類根據連結時期的不同,庫又有靜態庫和動態庫之分。靜態庫是在連結階段被連結的(好像是廢話,但事實就是這樣),所以生成的可執行檔案就不受庫的影響了,即使庫被刪除了,程式依然可以成功執行。有別於靜態庫,動態庫的連結是

Linux下RabbitMQ的編譯生成動態靜態

執行 編譯 ast lin 目錄 off href apt-get span 一、步驟 1、代碼托管處下載代碼 最新:https://github.com/alanxz/rabbitmq-c/archive/master.zip 穩定:https://g

QtEmbedded-4.8.6-arm 編譯選擇從 動態變化到靜態 時,生成的Makefile連結路徑下如果有動態靜態,優先選擇動態編譯應用

問題:QtEmbedded-4.8.6-arm 編譯選擇從 動態庫到靜態庫 時,發現的一個疑惑:,生成的Makefile連結庫路徑下如果有動態庫和靜態庫,優先選擇動態庫編譯應用 具體現象: 我最初是使用動態庫的 QtEmbedded-4.8.6-arm (編譯器選擇時,是 ./co

Linux下用Makefile製作動態靜態編譯生成可執行程式

Makefile 一個工程中的原始檔不計其數,其按型別、功能、模組分別放在若干個目錄中,makefile定義了一系列的規則來指定,哪些檔案需要先編譯,哪些檔案需要後編譯,哪些檔案需要重新

gcc動態靜態的連結順序

so檔案:動態庫 a檔案: 靜態庫 exe檔案:可執行程式(linux下以檔案屬性來標示是否是可執行檔案,與字尾名無關) gcc中連結順序問題,總結出以下幾點: 1,動態庫中可以包含另一個靜態庫,通過引數 -lxxx 把靜態庫libxxx.a加入so檔案中,這樣so檔案中 &nbs

編譯時混合使用動態靜態

         編譯某個測試程式碼時,出現了下面的錯誤:# g++ -std=c++11 -o testlurkcli main.cpp -L. -llurkcli-lasl -static /us

linux c/c++ 動態靜態生成與使用

二.介紹     從原始碼到可執行程式,通常要經過最重要的兩大步是:編譯,連結。編譯就是將原始檔生成中間檔案的過程,在linux下就是生成  .obj檔案。連結就是用連結器將,這些個中間檔案有序地”糅合“在一起,構成一個可執行檔案。通常,一個.c檔案或者.cpp原始檔編譯後,就會對應生成一個.obj檔案。  

linux下g++ 編譯動態靜態的連結標頭檔案問題

原來編譯的時候都是用的很隨意,沒用系統的總結一下,這幾天在編譯的時候遇到一些下問題,於是就總結一下,省得過幾天又給忘了。 1.動態庫和靜態庫簡介 靜態庫在程式連結的時候會自動的連結到程式裡,所以一旦編譯完成,靜態庫就不需要了,靜態庫以.a結尾。  動態庫在編譯時不會被連線到目的碼中,而是在程式執行

自己在linux上編譯、連結、動態靜態的學習筆記

在平常的專案中,我們都是使用公司要求的makefile、makedebug一類的檔案,因此,在編譯、連結、生成和連結動態庫與靜態庫的時候,我們只是簡單的使用一些已經設定的變數,只是簡單的修改、新增一些檔名,或許這次我們編譯通過了,但是,在某一個時候,可能出現了一個問題,無論

編譯動態靜態的Makefile模板

# 1、準備工作,編譯方式、目標檔名、依賴庫路徑的定義。 CC = gcc CFLAGS := -w -g -Wall LIB = libltkc.so HDRS = \ versi

動態靜態

linu not fine 執行文件 port pic 靜態庫 可執行 生成可執行文件 前提:本文是基於Linux系統下的編程與學習 補充:頭文件衛士,避免頭文件重復包含。 //頭文件衛士 #ifndef __HEAD_H__ #define __HEAD_H__ //頭

iOS裡的動態靜態

介紹 動態庫形式:.dylib和.framework 靜態庫形式:.a和.framework 動態庫和靜態庫的區別 靜態庫:連結時,靜態庫會被完整地複製到可執行檔案中,被多次使用就有多份冗餘拷貝(圖1所示) 系統動態庫:連結時不復制,程式執行時由系統動態

Linux 動態靜態

Linux作業系統中,依據函式庫是否被編譯到程式內部,將其分為兩大類,靜態函式庫和動態函式庫。 Linux下的函式庫放在/lib或/usr/lib,標頭檔案放在/usr/include。 在既有靜態庫又有動態庫的情況下,預設使用動態庫,如果強制使用靜態庫則需要加-static選項支援。

Linux中的動態靜態(.a.la.so.o)

​ Linux中的動態庫和靜態庫(.a/.la/.so/.o) 原文地址:https://www.cnblogs.com/findumars/p/5421910.html 在windows下,一般可以通過檔案的字尾名來識別檔案的型別。在Linux下大致上也是可以的。但是要明

Linux下動態靜態的連結

一、檢視連結了哪些指令 ldd 程式名字 二、在應用程式需要連線外部庫的情況下,linux預設對庫的連線是使用動態庫,在找不到動態庫的情況下再選擇靜態庫。使用方式為: gcc test.cpp -L. -ltestlib 如果當前目錄有兩個庫libtestlib.

Linux下怎麼建立動態靜態

前言 linux下的生成的動態庫和靜態庫沒有windows下方便 linux下gcc編譯預設動態連結和release 程式執行後呼叫動態庫 動態庫: 程式在執行的時候才去連結動態庫的程式碼,多個程式

Linux系統的動態靜態

靜態庫 靜態庫:一些公共程式碼是需要反覆使用,就把這些程式碼編譯為“庫”檔案;在連結步驟中,聯結器將從庫檔案取得所需的程式碼,複製到生成的可執行檔案中的這種庫。 程式編譯一般需經預處理、編譯、彙編和連結幾個步驟。靜態庫特點是可執行檔案中包含了庫程式碼的一份完整拷貝;缺點就是被多次

【Qt】Qt動態靜態的建立使用

動態庫(共享庫)的建立 在Qt Creator中新建專案,選擇Library 點選“Choose”進入下一步 選擇建立庫的型別:共享庫 選擇Kit套件 選擇需要的模組 配置工程路徑、名字等 Qt Creator自動建立的檔案

使用objdump檢視動態靜態中具有哪些函式

 我們在 Linux 下執行一個程式,有時會無法啟動,報缺少某某庫。這時需要檢視可執行程式或者動態庫中的符號表,動態庫的依賴項, Linux 有現成的工具可用:objdump 。 objdump 是 gcc 套件中用來檢視 ELF 檔案的工具,具體詳細用法不進行介紹,此