故事原因1， -fPIC与-Wl,Bsymbolic参数
今天有些工作没有做完，想趁星期一联调的时候解决一下。发现在编译自己的so的时候，总是提示错误：
R64_pc32_xx against ..., need to be recompiled with fPIC.
由于编译的so文件中使用了ffmpeg，提示的正是libavcodec.a其中的.o文件。
按网上的提示重新编译ffmpeg，比较正常的版本如下。
./configure --enable-pic --disable-yasm --disable-crystalhd --disable-vaapi
但是并没有完全解决上面的问题。
其中要加一个-wl,Bsymbolic，也就是在自己的so在链接的时候要强制自己使用本地的函数？
找到的解释如下：
在创建动态链接库时，gcc/g++选项中添加编译选项
-Wl,-Bsymbolic.
其中Wl表示将紧跟其后的参数，传递给连接器ld。Bsymbolic表示强制采用 本地的全局变量定义，这样就不会出现动态链接库的全局变量定义被应用程 序/动态链接库中的同名定义给覆盖了！
如果不想让主程序能存取动态库里的全局变量，则在链接动态连接库的时候，给gcc传入-Wl,-Bsymbolic即可
-Bsymbolic 当创建动态库时，如果某一个符号在全局符号表中已经存在，强制采用本地的；而缺省情况下，本地定义会被覆盖。这一点，对于保证多个动态库之间互不影响是很重要的，起码，它保证了本地定义的优先性，不会在程序员不知情的时候，偷偷用外部定义换掉。此外，如果想保证某一个动态库不会影响其他的动态库，则可以采用后面谈到的version-script选项；
但是这个为什么就解决了问题，还是不是非常清楚。
事故原因2，GCC的库依赖连接顺序的讲究
libswresample.a的位置有讲究，要放在比如说libavutil.a libavcodec.a等的后面
编译器的连接寻找重定位机制是有缺陷的吗？比如找不到swr_alloc，而实际上这个函数的实现是在libswresample.a中有实现的。
这个搜了一下，确实gcc有这个缺陷，被依赖的库要往后放，如果两个库相互依赖，那真的郁闷了。
在链接静态库时，如果多个静态库之间存在依赖关系，则有依赖关系的静态库之间存在链接顺序问题。这在使用静态库时需要注意，否则会报符号找不到的链接错误。 例如：lib2.a 依赖于 lib1.a，而最终可执行文件 test 依赖于 lib2.a，则链接选项应为：-llib2.a -llib1.a，而不能反过来，否则会报 lib1.a 中的某些符号未定义。
如果互相依赖这里有个解决的办法
你可能最终采取丑陋的做法,将其中一个库在前后放两次:gcc -o out.bin liba.ar libb.ar liba.ar -lrt
还有xlinker的办法：
最终的做法:gcc -o output.bin -Xlinker "-(" liba.ar libb.ar -Xlinker "-)" -lrt这样可以解决库顺序的问题了！问题是，如果你的库相互间的依赖如果错综复杂的话，可能会增加连接的时间，不过，做架构设计的都应该能考虑到这些问题吧。
其他的一些小的tips
- cp --force可以强制覆盖，但是要是同一个用户，不然也是没什么卵用的。
- rz --be可以解决zmodem connection timeout的问题。要记得add把文件加上。
- 还试着编译了以下boost库，希望能在本地的虚拟机器上搭建出完整的环境。但是boost从1.33到1.58现在的编译方法都不一样。
旧的版本为./build.sh,而新的版本为./bootstrap.sh，都是要先编译出bjam，但是在gcc下还是有很多error，unexpected token的错误。这个问题没有得到比较好的解决。
