在生成動態庫時，常常習慣性的加上fPIC選項，fPIC有什麼作用和意義，加不加有什麼區別，這裏做下小結：
fPIC的全稱是 Position Independent Code， 用於生成位置無關代碼。什麼是位置無關代碼，個人理解是代碼無絕對跳轉，跳轉都爲相對跳轉。
1、不加fPIC選項
即使不加fPIC也可以生成.so文件，但是對於源文件有要求，例如
因爲不加fPIC編譯的so必須要在加載到用戶程序的地址空間時重定向所有表目，所以在它裏面不能引用其它地方的代碼
如下：
#include <stdio.h>
int func1(int a)
{
printf("haha a=%d\n", 2);
a++;
return a;
}
使用 gcc -shared -o libb3.so c.c 編譯將報錯
/usr/bin/ld: /tmp/ccCViivC.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/tmp/ccCViivC.o: could not read symbols: Bad value
將上述代碼改爲：
int func1(int a)
{
// printf("haha a=%d\n", 2);
a++;
return a;
}
則可以編譯通過。
對於不加 -fPIC生成的動態庫，“ 生成動態庫時假定它被加載在地址 0 處。加載時它會被加載到一個地址（base），這時要進行一次重定位（relocation），把代碼、數據段中所有的地址加上這個 base 的值。這樣代碼運行時就能使用正確的地址了。”
2、加fPIC選項
加上fPIC選項生成的動態庫，顯然是位置無關的
“這樣的代碼本身就能被放到線性地址空間的任意位置，無需修改就能正確執行。通常的方法是獲取指令指針的值，加上一個偏移得到全局變量/函數的地址。”
加fPIC選項的 源文件對於，它引用的函數頭文件編寫有很寬鬆的尺度。
比如只需要包含個聲明的函數的頭文件，即使沒有相應的C文件來實現，編譯成so庫照樣可以通過。
在內存引用上，加不加fPIC的異同：
加了fPIC實現真正意義上的多個進程共享so文件。
多個進程引用同一個 PIC 動態庫時，可以共用內存。這一個庫在不同進程中的虛擬地址不同，但操作系統顯然會把它們映射到同一塊物理內存上。
對於不加-fPIC的
不加fPIC，則加載so文件時，需要對代碼段引用的數據對象需要重定位，重定位會修改代碼段的內容,這就造成每個使用這個.so文件代碼段的進程在內核裏都會生成這個.so文件代碼段的copy.每個copy都不一樣,取決於這個.so文件代碼段和數據段內存映射的位置。
可見，這種方式更消耗內存。
但是不加fPIC編譯的 so文件的優點是加載速度比較快。
題外話：能不能使用so庫來靜態編譯(-static)一個可執行程序，答案是否定的，會出現錯誤提示
attempted static link of dynamic object