makefile靜態編譯

『壹』 如何編譯靜態鏈接的程序，通過./configure 把參數-static傳入Makefile。

./configure LDFLAGS=-static

『貳』 makefile如何鏈接靜態庫

makefile 裡面寫法，同你的編譯器 如何鏈接靜態庫的方法有關。例如：指定庫名
VC++ 用 編譯選項 /MT 鏈接 LIBCMT.LIB 就是 鏈接靜態庫。
-----
unix/linux makefile 裡面，例如
LIBS = libmine.a -lpthread 這里寫你要鏈接的靜態庫庫名

CXXFILES = pthreads.cpp 程序名字們
CXXFLAGS = -O3 -o prog -rdynamic -D_GNU_SOURCE -L./libmine 編譯選項
LIBS = libmine.a -lpthread 庫名
all:

$(CXX) $(CXXFILES) $(LIBS) $(CXXFLAGS)
clean:

rm -f prog *.o

『叄』 如何用vs和makefile文件進行編譯

運行cmd.exe (or command.com in win9x)->進到vc/bin目錄->運行vc-vars32.bat->進到makefile 所在的目錄->nmake /f makefile
從sourceforge上下載下來的libjpeg源代碼中有一個makefile.vc的文件，可以通過nmake /f makefile.vc [nodebug=1]來編譯libjpeg，但是只能編譯靜態庫，如果需要編譯dll以便在emacs等程序中使用的話，需要修改makefile.vc和jmorecfg.h文件。在makefile.vc文件中添加編譯dll規則：
以下內容為程序代碼:
libjpeg.lib: $(LIBOBJECTS) $(RM) libjpeg.lib lib -out:libjpeg.lib $(LIBOBJECTS) #
添加以下這行 libjpeg.dll: $(LIBOBJECTS) $(RM) libjpeg.dll link -dll -out:libjpeg.dll $(LIBOBJECTS) 在jmorecfg.h中添加#define _WIN32_#define JPEG_DLL 然後nmake /f makefile.vc nodebug=1就可以編譯了。
將makefile復制為一個.mak文件，然後用VC打開即可！
.mak 就是一個makefile
可以指定怎樣編譯(命令行,必須先設置VC命令行環境)
vcvars32.bat可設置環境,在vc98/bin下 nmake /f XXXX.mak
如果有一個makefile就只要nmake就可以了。

『肆』 現在go可以靜態編譯一個程序么

第一步：all.bash

% cd $GOROOT/src
% ./all.bash

第一步有些突兀，因為 all.bash 僅僅調用了其它兩個 shell 腳本；make.bash 和 run.bash。如果你在使用 Windows 或 Plan 9，過程是一樣的，只是腳本擴展名變成了.bat 或.rc。對於本文中的其它腳本，請根據你的系統適當改動。
第二步：make.bash

. ./make.bash --no-banner

main.bash 來源於 all.bash，因此調用退出將正確終止便宜進程。main.bash 有三個主要工作，第一個是驗證編譯 Go 的環境是否完整。完整性檢查在過去幾年中建立，它通常嘗試避免使用已知的破損工具或必然失敗的環境進行編譯。
第三步. cmd/dist

gcc -O2 -Wall -Werror -ggdb -o cmd/dist/dist -Icmd/dist cmd/dist/*.c

一旦可用性檢查完畢，make.bash 將編譯產生 cmd/dist,cmd/dist取代了之前存在於Go 1 之前的Makefile 編譯系統。cmd/dist用來管理少量的pkg/runtime的代碼生成。cmd/dist 是C語言編寫的程序，能夠充分利用系統C編譯器和頭文件來處理大部分主機系統平台的檢測。cmd/dist通常用來檢測主機的操作系統和體系結構,即環境變數$GOHOSTOS和$GOHOSTARCH .如果是交叉編譯的話，變數 $GOOS和$GOARCH可能會由於你的設置而不同。事實上,Go 通常用作跨平台編譯器，只不過多數情況下，主機和目標系統一致而已。接下來，make.bash 調用cmd/dist 的引導參數的支持庫、 lib9、 libbio 和 libmach，使用編譯器套件，然後用自己的編譯器進行編譯。這些工具也是用 C 語言寫的中，但是由系統 C 編譯器編譯產生。

echo "# Building compilers and Go bootstrap tool for host, $GOHOSTOS/$GOHOSTARCH."
buildall="-a"
if [ "$1" = "--no-clean" ]; then
buildall=""
fi
./cmd/dist/dist bootstrap $buildall -v # builds go_bootstrap

使用的編譯器套件 cmd/dist 編譯產生一個版本的gotool，go_bootstrap。但go_bootstrap並不是完整得gotool，比方說 pkg/net 就是孤立的，避免了依賴於 cgo。要編譯的文件的列表以及它們的依賴項，是由cmd/dist編譯的 ，所以十分謹慎地避免引入新的生成依賴項 到 cmd/go。

第四步：go_bootstrap

現在， go_bootstrap 編譯完成了，make.bash 的最後一部就是使用 go_bootstrap 完成 Go 標准庫的編譯，包括整套 gotool 的替換版。

echo "# Building packages and commands for $GOOS/$GOARCH."
"$GOTOOLDIR"/go_bootstrap install -gcflags "$GO_GCFLAGS" \
-ldflags "$GO_LDFLAGS" -v std

第五步：run.bash

現在，make.bash 完成了，運行回到了 all.bash，它將引用 run.bash。run.bash 的工作是編譯和測試標准庫，運行時以及語言測試套件。

bash run.bash --no-rebuild

使用 --no-rebuild 標識是因為 make.bash 和 run.bash 可能都調用了 go install -a std，這樣可以避免重復，--no-rebuild 跳過了第二個 go install。

# allow all.bash to avoid double-build of everything
rebuild=true
if [ "$1" = "--no-rebuild" ]; then
shift
else
echo '# Building packages and commands.'
time go install -a -v std
echo
fi

第六步：go test -a std

echo '# Testing packages.'
time go test std -short -timeout=$(expr 120 \* $timeout_scale)s
echo

下一步 run.bash z則是對標准庫中的所有包進行單元測試，這是使用 testing 包編寫的。由於 $GOPATH 和 $GOROOT 中的代碼存在於同一個命名空間中，我們不能使用 go test，這可能會測試 $GOPATH 中的所有包，所以將創建別名std來標識標准庫中的包。由於有些測試需要很長時間，或耗用大量內存，測試將會通過 -short 標識將其過濾。
第七步 runtime 和 cgo 測試

run.bash的下一節將運行大量對cgo支持的平台測試，運行一些季春測試，編譯 Go 附帶的一些雜項程序。隨著時間的推移，這份雜項程序列表已經變長了，當它們發現自己並不包含在編譯過程中時，沉默將不可避免的被打破。

第八步： go run test

(xcd ../test
unset GOMAXPROCS
time go run run.go
) || exit $?

run.bash的倒數第二步調用了$GOROOT目錄下test文件夾中的編譯器和運行時測試。這其中有描述編譯器和運行時本身的低層級測試。而子目錄 test/bugs 及 test/fixedbugs 中的測試對已知問題和已解決問題進行特別的測試。所有測試的測試驅動器是 $GOROOT/test/run.go，該程序很小，它調用test文件夾中的每個.go 文件。有些 .go 文件在首行上描述了預期的運行結果，例如，程序失敗或是放出特定的輸出隊列。

第九步go tool api

echo '# Checking API compatibility.'
go tool api -c $GOROOT/api/go1.txt,$GOROOT/api/go1.1.txt \
-next $GOROOT/api/next.txt -except $GOROOT/api/except.txt

run.bash的最後一部將調用API工具，API工具的作用是執行 Go 1 約定；導出的符號，常數，函數，變數，類型和方法組成2012年確認的 Go 1 API。Go 1 寫在 api/go1.txt 文件，而 Go 1.1 則寫在 api/go1.1.txt文件中。另一個額外的文件，api/next.txt 描述了G 1.1自後添加到標准庫和運行時中的符號。當 Go 1.2 發布時，這個文件將會成為 Go 1.2 的約定，另一個新的 next.txt 文件也將被創建。這里還有一個小文件，except.txt，它包括 Go 1 約定中被批準的擴展。對文件的增添總是小心翼翼的。

『伍』 在VC里如何用Makefile文件編譯

運行cmd.exe (or command.com in win9x)->進到vc/bin目錄->運行vc-vars32.bat->進到makefile 所在的目錄->nmake /f makefile
從sourceforge上下載下來的libjpeg源代碼中有一個makefile.vc的文件，可以通過nmake /f makefile.vc [nodebug=1]來編譯libjpeg，但是只能編譯靜態庫，如果需要編譯dll以便在emacs等程序中使用的話，需要修改makefile.vc和jmorecfg.h文件。在makefile.vc文件中添加編譯dll規則：
以下內容為程序代碼:
libjpeg.lib: $(LIBOBJECTS) $(RM) libjpeg.lib lib -out:libjpeg.lib $(LIBOBJECTS) #
添加以下這行 libjpeg.dll: $(LIBOBJECTS) $(RM) libjpeg.dll link -dll -out:libjpeg.dll $(LIBOBJECTS) 在jmorecfg.h中添加#define _WIN32_#define JPEG_DLL 然後nmake /f makefile.vc nodebug=1就可以編譯了。
將makefile復制為一個.mak文件，然後用VC打開即可！
.mak 就是一個makefile
可以指定怎樣編譯(命令行,必須先設置VC命令行環境)
vcvars32.bat可設置環境,在vc98/bin下 nmake /f XXXX.mak
如果有一個makefile就只要nmake就可以了。

『陸』 makefile的選項CFLAGS，CPPFLAGS，LDFLAGS和LIBS的區別

Linux內核的配置系統由三個部分組成，分別是：Makefile：分布在 Linux 內核源代碼中的 Makefile，定義 Linux 內核的編譯規則； 配置文件（config.in）：給用戶提供配置選擇的功能； 配置工具：包括配置命令解釋器（對配置腳本中使用的配置命令進行解釋）和配置用戶界面（提供基於字元界面、基於 Ncurses 圖形界面以及基於 Xwindows 圖形界面的用戶配置界面，各自對應於 Make config、Make menuconfig 和 make xconfig）。這些配置工具都是使用腳本語言，如 Tcl/TK、Perl 編寫的（也包含一些用 C 編寫的代碼）。本文並不是對配置系統本身進行分析，而是介紹如何使用配置系統。所以，除非是配置系統的維護者，一般的內核開發者無須了解它們的原理，只需要知道如何編寫 Makefile 和配置文件就可以。所以，在本文中，我們只對 Makefile 和配置文件進行討論。另外，凡是涉及到與具體 CPU 體系結構相關的內容，我們都以 ARM 為例，這樣不僅可以將討論的問題明確化，而且對內容本身不產生影響。2． Makefile2.1 Makefile 概述Makefile 的作用是根據配置的情況，構造出需要編譯的源文件列表，然後分別編譯，並把目標代碼鏈接到一起，最終形成 Linux 內核二進制文件。由於 Linux 內核源代碼是按照樹形結構組織的，所以 Makefile 也被分布在目錄樹中。Linux 內核中的 Makefile 以及與 Makefile 直接相關的文件有：Makefile：頂層 Makefile，是整個內核配置、編譯的總體控制文件。 .config：內核配置文件，包含由用戶選擇的配置選項，用來存放內核配置後的結果（如 make config）。 arch/*/Makefile：位於各種 CPU 體系目錄下的 Makefile，如 arch/arm/Makefile，是針對特定平台的 Makefile。 各個子目錄下的 Makefile：比如 drivers/Makefile，負責所在子目錄下源代碼的管理。 Rules.make：規則文件，被所有的 Makefile 使用。 用戶通過 make config 配置後，產生了 .config。頂層 Makefile 讀入 .config 中的配置選擇。頂層 Makefile 有兩個主要的任務：產生 vmlinux 文件和內核模塊（mole）。為了達到此目的，頂層 Makefile 遞歸的進入到內核的各個子目錄中，分別調用位於這些子目錄中的 Makefile。至於到底進入哪些子目錄，取決於內核的配置。在頂層 Makefile 中，有一句：include arch/$(ARCH)/Makefile，包含了特定 CPU 體系結構下的 Makefile，這個 Makefile 中包含了平台相關的信息。位於各個子目錄下的 Makefile 同樣也根據 .config 給出的配置信息，構造出當前配置下需要的源文件列表，並在文件的最後有 include $(TOPDIR)/Rules.make。Rules.make 文件起著非常重要的作用，它定義了所有 Makefile 共用的編譯規則。比如，如果需要將本目錄下所有的 c 程序編譯成匯編代碼，需要在 Makefile 中有以下的編譯規則：%.s: %.c$(CC) $(CFLAGS) -S $< -o $@有很多子目錄下都有同樣的要求，就需要在各自的 Makefile 中包含此編譯規則，這會比較麻煩。而 Linux 內核中則把此類的編譯規則統一放置到 Rules.make 中，並在各自的 Makefile 中包含進了 Rules.make（include Rules.make），這樣就避免了在多個 Makefile 中重復同樣的規則。對於上面的例子，在 Rules.make 中對應的規則為：%.s: %.c$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(*F)) $(CFLAGS_$@) -S $< -o [email protected] Makefile 中的變數頂層 Makefile 定義並向環境中輸出了許多變數，為各個子目錄下的 Makefile 傳遞一些信息。有些變數，比如 SUBDIRS，不僅在頂層 Makefile 中定義並且賦初值，而且在 arch/*/Makefile 還作了擴充。常用的變數有以下幾類：1） 版本信息版本信息有：VERSION，PATCHLEVEL, SUBLEVEL, EXTRAVERSION，KERNELRELEASE。版本信息定義了當前內核的版本，比如 VERSION=2，PATCHLEVEL=4，SUBLEVEL=18，EXATAVERSION=-rmk7，它們共同構成內核的發行版本KERNELRELEASE：2.4.18-rmk72） CPU 體系結構：ARCH在頂層 Makefile 的開頭，用 ARCH 定義目標 CPU 的體系結構，比如 ARCH:=arm 等。許多子目錄的 Makefile 中，要根據 ARCH 的定義選擇編譯源文件的列表。3） 路徑信息：TOPDIR, SUBDIRSTOPDIR 定義了 Linux 內核源代碼所在的根目錄。例如，各個子目錄下的 Makefile 通過 $(TOPDIR)/Rules.make 就可以找到 Rules.make 的位置。SUBDIRS 定義了一個目錄列表，在編譯內核或模塊時，頂層 Makefile 就是根據 SUBDIRS 來決定進入哪些子目錄。SUBDIRS 的值取決於內核的配置，在頂層 Makefile 中 SUBDIRS 賦值為 kernel drivers mm fs net ipc lib；根據內核的配置情況，在 arch/*/Makefile 中擴充了 SUBDIRS 的值，參見4）中的例子。4） 內核組成信息：HEAD, CORE_FILES, NETWORKS, DRIVERS, LIBSLinux 內核文件 vmlinux 是由以下規則產生的：vmlinux: $(CONFIGURATION) init/main.o init/version.o linuxsubdirs$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o --start-group $(CORE_FILES) $(DRIVERS) $(NETWORKS) $(LIBS) --end-group -o vmlinux可以看出，vmlinux 是由 HEAD、main.o、version.o、CORE_FILES、DRIVERS、NETWORKS 和 LIBS 組成的。這些變數（如 HEAD）都是用來定義連接生成 vmlinux 的目標文件和庫文件列表。其中，HEAD在arch/*/Makefile 中定義，用來確定被最先鏈接進 vmlinux 的文件列表。比如，對於 ARM 系列的 CPU，HEAD 定義為： HEAD := arch/arm/kernel/head-$(PROCESSOR).o arch/arm/kernel/init_task.o表明 head-$(PROCESSOR).o 和 init_task.o 需要最先被鏈接到 vmlinux 中。PROCESSOR 為 armv 或 armo，取決於目標 CPU。 CORE_FILES，NETWORK，DRIVERS 和 LIBS 在頂層 Makefile 中定義，並且由 arch/*/Makefile 根據需要進行擴充。 CORE_FILES 對應著內核的核心文件，有 kernel/kernel.o，mm/mm.o，fs/fs.o，ipc/ipc.o，可以看出，這些是組成內核最為重要的文件。同時，arch/arm/Makefile 對 CORE_FILES 進行了擴充：# arch/arm/Makefile# If we have a machine-specific directory, then include it in the build.MACHDIR := arch/arm/mach-$(MACHINE)ifeq ($(MACHDIR),$(wildcard $(MACHDIR)))SUBDIRS += $(MACHDIR)CORE_FILES := $(MACHDIR)/$(MACHINE).o $(CORE_FILES)endifHEAD := arch/arm/kernel/head-$(PROCESSOR).o arch/arm/kernel/init_task.oSUBDIRS += arch/arm/kernel arch/arm/mm arch/arm/lib arch/arm/nwfpeCORE_FILES := arch/arm/kernel/kernel.o arch/arm/mm/mm.o $(CORE_FILES)LIBS := arch/arm/lib/lib.a $(LIBS)5） 編譯信息：CPP, CC, AS, LD, AR，CFLAGS，LINKFLAGS在 Rules.make 中定義的是編譯的通用規則，具體到特定的場合，需要明確給出編譯環境，編譯環境就是在以上的變數中定義的。針對交叉編譯的要求，定義了 CROSS_COMPILE。比如：CROSS_COMPILE = arm-linux-CC = $(CROSS_COMPILE)gccLD = $(CROSS_COMPILE)ld......CROSS_COMPILE 定義了交叉編譯器前綴 arm-linux-，表明所有的交叉編譯工具都是以 arm-linux- 開頭的，所以在各個交叉編譯器工具之前，都加入了 $(CROSS_COMPILE)，以組成一個完整的交叉編譯工具文件名，比如 arm-linux-gcc。CFLAGS 定義了傳遞給 C 編譯器的參數。LINKFLAGS 是鏈接生成 vmlinux 時，由鏈接器使用的參數。LINKFLAGS 在 arm/*/Makefile 中定義，比如：# arch/arm/MakefileLINKFLAGS :=-p -X -T arch/arm/vmlinux.lds6） 配置變數CONFIG_*.config 文件中有許多的配置變數等式，用來說明用戶配置的結果。例如 CONFIG_MODULES=y 表明用戶選擇了 Linux 內核的模塊功能。.config 被頂層 Makefile 包含後，就形成許多的配置變數，每個配置變數具有確定的值：y 表示本編譯選項對應的內核代碼被靜態編譯進 Linux 內核；m 表示本編譯選項對應的內核代碼被編譯成模塊；n 表示不選擇此編譯選項；如果根本就沒有選擇，那麼配置變數的值為空。2.3 Rules.make 變數前面講過，Rules.make 是編譯規則文件，所有的 Makefile 中都會包括 Rules.make。Rules.make 文件定義了許多變數，最為重要是那些編譯、鏈接列表變數。O_OBJS，L_OBJS，OX_OBJS，LX_OBJS：本目錄下需要編譯進 Linux 內核 vmlinux 的目標文件列表，其中 OX_OBJS 和 LX_OBJS 中的 "X" 表明目標文件使用了 EXPORT_SYMBOL 輸出符號。M_OBJS，MX_OBJS：本目錄下需要被編譯成可裝載模塊的目標文件列表。同樣，MX_OBJS 中的 "X" 表明目標文件使用了 EXPORT_SYMBOL 輸出符號。O_TARGET，L_TARGET：每個子目錄下都有一個 O_TARGET 或 L_TARGET，Rules.make 首先從源代碼編譯生成 O_OBJS 和 OX_OBJS 中所有的目標文件，然後使用 $(LD) -r 把它們鏈接成一個 O_TARGET 或 L_TARGET。O_TARGET 以 .o 結尾，而 L_TARGET 以 .a 結尾。

『柒』 我寫了個Makefile文件 指定調用我自己編譯的靜態庫 怎麼每次系統都從/usr/lib下面查找

你在makefile中指定所鏈接庫的位置了么？？
在你的makefile中寫編譯規則的地方加上 -L/home/zhangcl/lib 就好了

『捌』 makefile 生成動態庫和靜態庫的區別

生成
動態庫
的時候要注意，編譯生成目標文件的時候加上-fPIC參數，生成位置無關的可重定位代碼，然後鏈接的時候加上-shared生成動態共享庫。比如一個hello.c，生成靜態庫：
1
2

gcc -o hello.o -c hello.c
ar rcs libhello.a hello.o

生成動態庫的命令：
1
2

gcc -fPIC hello.o -c hello.c
gcc -shared -o libhelllo.so hello.o

還有一個區別是：靜態庫參與鏈接過程，而動態庫不鏈接到可執行文件中，
可執行程序
在運行的時候，對應的動態庫也要載入到內存中，否則可執行程序運行不了。

『玖』 多級目錄makefile，靜態庫

在lib 目錄下編譯需要生成動態庫的文件，生成動態庫，並安裝到系統的標准庫中，供
程序調用。具體步驟如下：
(1) 編寫Makefile.am 文件
AUTOMAKE_OPTIONS=foreign
lib_LTLIBRARIES=libhello.la
libhello_la_SOURCES=test.c
這里lib_LTLIBRARIES 的意思是生成的動態庫，然後指定動態庫依賴的源文件
test.c ，若有多個源文件用空格隔開。
(2) 在lib 目錄下，用命令autoscan 產生configure.scan 文件,並改名為configure.in。 這
里需加上宏AC_PROG_LIBTOOL，表示利用libtool 來自動生成動態庫
#configure.in
# Process this file with autoconf to proce a configure script.
AC_PREREQ(2.59)
AC_INIT(hello,1.0, [[email protected]])
AM_INIT_AUTOMAKE
AC_CONFIG_SRCDIR([test.c])
#AC_CONFIG_HEADER([config.h])
# Checks for programs.
AC_PROG_CC
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
AC_PROG_LIBTOOL
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
(3) 執行命令aclocal、libtoolize -f -c 、autoconf、automake --add-missing、./configure、
make、make install 將動態庫安裝到系統的標准庫中，以供調用（一般為/usr/local/lib）。
註：libtoolize 提供了一種標準的方式來將libtool 支持加入一個軟體包，而GNU libtool 是
一個通用庫支持腳本，將使用動態庫的復雜性隱藏在統一、可移植的介面中。
4. 生成src 目錄下的hello 可執行文件
(1) 編寫src/Makefile.am 文件
AUTOMAKE_OPTIONS=foreign
INCLUDES= -I../include
bin_PROGRAMS=hello
hello_SOURCES=hello.c
hello_LDADD=-lhello
-ldir 指定編譯時搜索庫的路徑。與靜態庫不同的是，創建動態庫時不用指定庫路
徑，編譯器自動在標准庫中查找libhello.so 文件。
(2) 執行autoscan 生成configure.scan 文件，將它重命名為configure.in 並修改其內容。
# configure.in
# Process this file with autoconf to proce a configure script.
AC_PREREQ(2.59)
AC_INIT(hello,1.0, [[email protected]])
AM_INIT_AUTOMAKE
AC_CONFIG_SRCDIR([hello.c])
#AC_CONFIG_HEADER([config.h])
# Checks for programs.
AC_PROG_CC
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
(3) 在src 目錄下編譯並生成目標文件，執行命令aclocal、libtoolize -f -c 、autoconf、
automake --add-missing、./configure、make，此時你一定會覺得，成功近在咫尺了。再
執行目標文件./hello，結果卻在你的意料之外：
./hello: error while loading shared libraries: libhello.so.0 : cannot open shared object file:
No such file or directory
在執行目標文件的時候，Shell 找不到共享庫的位置，需要我們手工載入庫路徑。
5. shell 搜索動態庫路徑位置的兩種方法
(1) 使用命令導入動態庫的路徑，命令如下：
export LD_LIBRARY_PATH=dir (如/usr/local/lib)
(2) 修改/etc/ld.so.conf 文件，加入搜索路徑，修改後用ldconfig 命令載入修改。
將自己可能存放庫文件的路徑都加入到/etc/ld.so.conf 中是明智的選擇 ^_^。添加
方法也極其簡單，將庫文件的絕對路徑直接寫進去就OK 了，一行一個。例如：
/usr/local/lib
/usr/lib
/lib
需要注意的是：這種搜索路徑的設置方式對於程序連接時的庫（包括共享庫和靜態
庫）的定位已經足夠了，但是對於使用了共享庫的程序的執行還是不夠的。這是 因為
為了加快程序執行時對共享庫的定位速度，避免使用搜索路徑查找共享庫的低效率，所
以是直接讀取庫列表文件 /etc/ld.so.cache 從中進行搜索的。/etc/ld.so.cache 是一個非
文本的數據文件，不能直接編輯，它是根據 /etc/ld.so.conf 中設置的搜索路徑由
/sbin/ldconfig 命令將這些搜索路徑下的共享庫文件集中在一起而生成的（ldconfig 命令
要以 root 許可權執行）。因此，為了保證程序執行時對庫的定位，在 /etc/ld.so.conf 中
進行了庫搜索路徑的設置之後，還必須要運行 /sbin/ldconfig 命令更新 /etc/ld.so.cache
文件之後才可以。ldconfig ,簡單的說，它的作用就是將/etc/ld.so.conf 列出的路徑下的庫
文件 緩存到/etc/ld.so.cache 以供使用。因此當安裝完一些庫文件，(例如剛安裝好glib)，
或者修改ld.so.conf 增加新的庫路徑後，需要運行一下/sbin/ldconfig 使所有的庫文件都
被緩存到ld.so.cache 中，如果沒做，即使庫文件明明就在/usr/lib 下的，也是不會被使
用的，結果編譯過程中報錯，缺少xxx 庫，去查看發現明明就在那放著，搞的想大罵
computer 蠢豬一個^_^。極力推薦使用這種方法！
利用gcc 創建和使用動態庫
1. 用下面的命令將mylib.c 程序創建成一個動態庫：
gcc –fPIC –o mylib.o –c mylib.c
gcc –shared –o libtt.so mylib.o
-fPIC 作用於編譯階段，告訴編譯器產生與位置無關代碼(Position-Independent Code)，
則產生的代碼中，沒有絕對地址，全部使用相對地址，故而代碼可以被載入器載入到內存的
任意位置，都可以正確的執行。這正是共享庫所要求的，共享庫被載入時，在內存的位置不
是固定的。
-shared 作用於鏈接階段，實際傳遞給鏈接器ld，讓其添加作為共享庫所需要的額外描
述信息，去除共享庫所不需的信息。
也可以直接使用下面一條命令：
gcc –fPIC –shared –o libtt.so mylib.c
2. 將動態庫拷貝到linux 的標准庫中，usr/local/lib 或者/usr/lib 或者/lib:
cp libttt.so /usr/local/lib
3. 編譯src 目錄下的源程序時，指定動態庫文件的目錄，調用動態庫中的函數
gcc –o test test.c /usr/lib/libttt.so
4. 設置shell 動態庫搜索路徑，運行生成的可執行文件。