linux下使用共享库的软链接,关于Linux共享库的软连接的copy以及strip共享库与flash size的问题...

1. 对于库文件的软链接操作不能直接copy而应该用cp –P

通常我们编译open

source的时候，会生成一些共享库供其他application使用，最终会copy到fs.install/lib/目录下，请大家注意相关的copy操作可能会引起一些flash

size的使用问题。

一般情况下，以openssl的libcrypto库而言，最终生成的是libcrypto.so.0.9.7这样的文件，而对于其他application如果要使用共享库，通常会以-lcrypto的方式链接，而-lcrypto一般情况下标准的引用方式是libcrypto.so而不是libcrypto.so.0.9.7，这个时候需要做的动作就会生成一个libcrypto.so的软链接“ln

–s libcrypto.so.0.9.7 libcrypto.so”,

最后将这两个文件一起copy到fs.install/lib/中。

正常情况，makefile会做这样的软链接，如果没有可以自己用上诉命令添加，但是目前见到的情况是通常我们在不知道的情况下，直接的copy动作导致最终放入CPE的libcrypto.so不是一个软链接文件而是一个libcrypto.so.0.9.7的文件.

对于软链接的文件正确的cp命令应该是加上-P的参数“cp  –P xxx xxx”

以上诉的libcrypto为例，原始编译出来的软链接

Copy 到fs.install/lib/目录下

两者的差距是1197387-14 = 1169K

目前这种情况在压缩后不会引起flash占用的问题，实际编译出来的FW大小是一样的，应该是压缩算法cover了这种情况

但是从正常的情况来看，这种操作是不对的，对于只占用flash的文件结果是没有问题的，如果以后出现需要在内存中放置类似文件的问题，就会引起memory的占用问题。

所以建议大家以后在编译动态链接库的时候按照上面的流程进行正常的操作。

2. 对于编译生成的可执行文件和库文件，强制用strip.

Strip可以用来对编译出来的应用程序进行裁剪，做downsize的动作，所以开发新的open

source的时候务必需要对可执行文件做相应的strip动作.

另外对于动态链接库而言*.so，应该可以同样做strip的动作，目前MTK也是这么做的，鉴于网络上有提到动态链接库的strip，建议可以保持目前没有被strip的库，在开发新的open

source的库时应该default也做strip库文件的动作，如果RD的feature的测试ok，应该就是可行的

PS:

个把极端的情况，如Fon的build在做完上诉操作后，压缩后的FW的size差别大约有250K左右.

3．

关于软链接的使用，有时候也可以很灵活，对于要应用其他application的库文件或是头文件，除了可以在makefile中指定头文件或库文件的非标准位置外，应该并不需要用到copy的方法，只需要create一个对应的文件或是文件夹的软链接即可解决将需要的文件copy过来的问题，这种情况对于单个库文件可以用处不大，但是对于引用众多文件的时候文件夹的链接也许更简单方便。