动态库加载出错，cannot restore segment prot after reloc: Permission denied以及为何编译动态库需要-fPIC
项目中碰到的问题，编译好的so文件，放到其他机器上去加载，报了错误，cannot restore segment prot after reloc: Permission denied。
网上查了一下，原因是selinux的问题，selinux的设置太过严格导致的。解决的办法是在root用户下，修改/etc/selinux/config 文件，
把SELINUX=enforcing 改成 SELINUX=disabled。然后，保存关闭，重启机器就可以了。
另外还有一个暂时关闭的方法，就是 /usr/sbin/setenforce 0 。
此外呢，我自己在犄角旮旯里发现了另外一个方法，举个例子，你碰到问题的so文件是test.so，
那么
chcon -t texrel_shlib_t test.so 就可以了。不过呢，这个命令只能修改一个so，如果想让你的系统以后都不会碰到这个错误，那最好还是采用修改文件
的方式。
如果你只是来看怎么解决这个问题的，那下面的就不用看了，下面是说gcc的编译命令-fPIC的作用。源自点击打开链接。记住，-fPIC是编译命令，-shared是链接命令。
编译GNU/Linux共享库, 为什么要用PIC编译?
from 《
Binary Hacks:黑客秘笈100选》
一直以为不管是编译共享库还是静态库，中间生成的目标文件(.o文件)是没有区别的，区别只在:最后是用-shared编译还是用ar打包； 可是事情的真相并不是这样的：
本hack中， 我们来研究编译共享库时，为什么要用PIC(选项)编译？
通常编译GNU/Linux共享库时，把各个.c文件编译编译成PIC(Position Independent Code, 位置无关代码)。但是，实际上不用PIC编译的话也可以编译共享库。那么使用PIC还有意义吗？
让我们来进行一个实验：
#include
void func() {
printf(" ");
printf(" ");
printf(" ");
} 用 PIC编译必须把参数-fpic或-fPIC传给gcc，-fpic可以生成小而高效的代码，但是不同的处理器中-fpic生成的GOT(Global Offset Table, 全局偏移表)的大小有限制，另一方面，使用-fPIC的话，任何处理器都可以放心使用。在这里，使用-fPIC。(在X86中使用-fpic和-fPIC 没有任何区别)。
$ gcc -o fpic-no-pic.s -S fpic.c
$ gcc -fPIC -o fpic-pic.s -S fpic.c阅读上述生成的汇编代码，则可以知道PIC版本通过PLT(Procedure Linkage Table)调用printf。
$ grep printf fpic-no-pic.s
call printf
call printf
call printf
$ grep printf fpic-pic.s
call printf@PLT
call printf@PLT
call printf@PLT $ gcc -shared -o fpic-no-pic.so fpic.c
$ gcc -shared -fPIC -o fpic-pic.so fpic.c $ readelf -d fpic-no-pic.so | egrep 'TEXTREL|RELCOUNT'
0x00000016 (TEXTREL) 0x0
0x6ffffffa (RELCOUNT) 5
$ readelf -d fpic-pic.so | egrep 'TEXTREL|RELCOUNT'
0x6ffffffa (RELCOUNT) 2PIC版本的RELCOUNT非0是由于gcc在缺省时使用的是包含在启动文件里的代码。若加-nostartfiles选项，则RELCOUNT值为0。
PIC和非PIC共享库的性能对比
上面例子阐述了非PIC版本运行时(动态运行时)需要5个地址的再分配。那么，若在配置的数量大增时会出现什么样的情况呢？
运行下面的shell脚本，用非PIC版本和PIC版本编译含有1000万次printf()调用的共享库，和相应的可执行文件fpic-no-pic和fpic-pic。
#! /bin/sh
rm -f *.o *.so
num=1000
for i in `seq $num`; do
echo -e "#include \nvoid func$i() {" >fpic$i.c
#ruby -e "10000.times { puts 'printf(\" \");' }" >>fpic$i.c
perl -e 'print("printf(\" \");\n"x10000);' >>fpic$i.c
echo "}" >> fpic$i.c
gcc -o fpic-no-pic$i.o -c fpic$i.c
gcc -o fpic-pic$i.o -fPIC -c fpic$i.c
done
gcc -o fpic-no-pic.so -shared fpic-no-pic*.o
gcc -o fpic-pic.so -shared fpic-pic*.o
echo "int main() { return 0; }" >fpic-main.c
gcc -o no-pic-load fpic-main.c ./fpic-no-pic.so
gcc -o pic-load fpic-main.c ./fpic-pic.so
echo "int main() {" >main.c
for i in `seq $num`; do echo "func$i();"; done >>main.c
echo "}" >>main.c
gcc -o fpic-no-pic main.c ./fpic-no-pic.so
gcc -o fpic-pic main.c ./fpic-pic.so 两个版本程序，运行结果如下： 非PIC版本首次运行时间2.15秒，第二次以后大约0.55秒，而PIC版本的首次用了0.02秒，第二次以后用了0.00秒。
$ repeat 3 time ./no-pic-load
2.15s total : 0.29s user 0.48s system 35% cpu
0.56s total : 0.25s user 0.31s system 99% cpu
0.55s total : 0.30s user 0.25s system 99% cpu
$ repeat 3 time ./pic-load
0.02s total : 0.00s user 0.00s system 0% cpu
0.00s total : 0.00s user 0.01s system 317% cpu
0.00s total : 0.00s user 0.00s system 0% cpumain() 本身是空的，可以知道非PIC版本动态链接时的再分配需要2.15~0.55秒。运行环境Xeon-2.8GHz+Debian GNU/Linux sarge+GCC 3.3.5。
非PIC版本的缺点不仅是在运行时再配置上花时间。为了更新再配置部分的代码，将会发生这样的情况(下载text segment里需要再配置的页->更新->进行copy on write -> 不能与其他路径和text共享)。
另外比较非PIC版本的fpic-no-pic.so和PIC版本的fpic-pic.so的大小，前者268M，后者134M，差别很明显。用readelf -S查看节头，会有以下区别：
.rel.dyn .text
非PIC 152MB 114MB
PIC 0MB 133MB非PIC版本的代码(.text)比PIC版本的小，但再配置所需要的信息占很大的空间。