交叉編譯的時候不能使用本地（i686機器，即PC機器，研發機器）機器上的庫，但是在做編譯鏈接的時候默認的是使用本地庫，即/usr/lib,/lib兩個目錄。因此，在交叉編譯的時候，要采取一些方法使得在編譯鏈接的時候找到需要的庫。
首先，要知道：編譯的時候只需要頭文檔，真正實際的庫文檔在鏈接的時候用到。 （這是我的理解，假如有不對的地方，敬請網上各位大俠指教） 然后，講講如何在交叉編譯鏈接的時候找到需要的庫。
（1）、交叉編譯時候直接使用-L和-I參數指定搜索非標准的庫文檔和頭文檔的路徑。例如：
arm-linux-gcc test.c -L/usr/local/arm/2.95.3/arm-linux/lib -I/usr/local/arm/2.95.3/arm-linux/include
（2）、使用ld.so.conf文檔，將用到的庫所在文檔目錄添加到此文檔中，然后使用ldconfig命令刷新緩存。
（3）、使用如下命令：
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/arm/2.95.3/arm-linux-lib
參見《ld.so.conf 文檔和PKG_CONFIG_PATH變量》這篇文章。
通過環境變量LD_LIBRARY_PATH指定動態庫搜索路徑（！）。
通過設定環境變量LD_LIBRARY_PATH也可以指定動態庫搜索路徑。當通過該環境變量指定多個動態庫搜索路徑時，路徑之間用冒號"："分隔。
不過LD_LIBRARY_PATH的設定作用是全局的，過多的使用可能會影響到其他應用程序的運行，所以多用在調試。（LD_LIBRARY_PATH的缺陷和使用准則，可以參考《Why LD_LIBRARY_PATH is bad》 ）。通常情況下推薦還是使用gcc的-R或-rpath選項來在編譯時就指定庫的查找路徑，並且該庫的路徑信息保存在可執行文件中，運行時它會直接到該路 徑查找庫，避免了使用LD_LIBRARY_PATH環境變量查找。
（4）、交叉編譯時使用軟件的configure參數。例如我編譯minigui-1.3.3，使用如下配置：
#!/bin/bash
rm -f config.cache config.status
./configure --build=i686-linux --host=arm-linux --target=arm-linux \
CFLAGS=-I/usr/local/arm/2.95.3/arm-linux/include \
LDFLAGS=-L/usr/local/arm/2.95.3/arm-linux/lib \
--prefix=/usr/local/arm/2.95.3/arm-linux \
--enable-lite \
--disable-galqvfb \
--disable-qvfbial \
--disable-vbfsupport \
--disable-ttfsupport \
--disable-type1support \
--disable-imegb2312py \
--enable-extfullgif \
--enable-extskin \
--disable-videoqvfb \
--disable-videoecoslcd
這里我配置了CFLAGS和LDFLAGS參數，這樣一來，我就不用去修改每個Makefile里-L和-I參數了，也不用再去配置LD_LIBRARY_PATH或改寫ld.so.conf文檔了。
Linux下動態庫使用小結
1. 靜態庫和動態庫的基本概念
靜態庫，是在可執行程序連接時就已經加入到執行碼中，在物理上成為執行程序的一部分；使用靜態庫編譯的程序運行時無需該庫文件支持，哪里都可以用，但是生成的可執行文件較大。動態庫，是在可執行程序啟動時加載到執行程序中，可以被多個可執行程序共享使用。使用動態庫編譯生成的程序相對較小，但運行時需要庫文件支持，如果機器里沒有這些庫文件就不能運行。
2． 如何使用動態庫
如何程序在連接時使用了共享庫，就必須在運行的時候能夠找到共享庫的位置。linux的可執行程序在執行的時候默認是先搜索/lib和/usr/lib這兩個目錄，然后按照/etc/ld.so.conf里面的配置搜索絕對路徑。同時，Linux也提供了環境變量LD_LIBRARY_PATH供用戶選擇使用，用戶可以通過設定它來查找除默認路徑之外的其他路徑，如查找/work/lib路徑,你可以在/etc/rc.d/rc.local或其他系統啟動后即可執行到的腳本添加如下語句：LD_LIBRARY_PATH =/work/lib:$(LD_LIBRARY_PATH)。並且LD_LIBRARY_PATH路徑優先於系統默認路徑之前查找（詳細參考《使用LD_LIBRARY_PATH》）。
不過LD_LIBRARY_PATH的設定作用是全局的，過多的使用可能會影響到其他應用程序的運行，所以多用在調試。（LD_LIBRARY_PATH的缺陷和使用准則，可以參考《Why LD_LIBRARY_PATH is bad》 ）。通常情況下推薦還是使用gcc的-R或-rpath選項來在編譯時就指定庫的查找路徑，並且該庫的路徑信息保存在可執行文件中，運行時它會直接到該路徑查找庫，避免了使用LD_LIBRARY_PATH環境變量查找。
3．庫的鏈接時路徑和運行時路徑
現代連接器在處理動態庫時將鏈接時路徑（Link-time path）和運行時路徑（Run-time path）分開,用戶可以通過-L指定連接時庫的路徑，通過-R（或-rpath）指定程序運行時庫的路徑，大大提高了庫應用的靈活性。比如我們做嵌入式移植時#arm-linux-gcc $(CFLAGS) –o target –L/work/lib/zlib/ -llibz-1.2.3 (work/lib/zlib下是交叉編譯好的zlib庫)，將target編譯好后我們只要把zlib庫拷貝到開發板的系統默認路徑下即可。或者通過-rpath（或-R ）、LD_LIBRARY_PATH指定查找路徑。
小問題：
1．編譯時的-L選項是否影響LD_LIBRARY_PATH的值？
舉一個實例：
當前文件夾結構如下：
test.c tools/
tool下有tool.c tool.h my_err.h 以及由此生成的libtool.so
tool下編譯生成庫文件
gcc -Wall -g -shared -o tool.so tool.c
在當前文件夾引用：
gcc -Wall -g –o test.c -Ltools -ltool
編譯不報錯，但是運行加載的時候就出現cannot open shared object file。
如果將該庫文件拷貝到/usr/lib下就沒有錯誤，正常運行。
說明編譯時的-L選項並不影響環境變量LD_LIBRARY_PATH，-L只是指定了程序編譯連接時庫的路徑，並不影響程序執行時庫的路徑，系統還是會到默認路徑下查找該程序所需要的庫。