当前位置: 技术问答>linux和unix
(在线等待)如果把一个静态库整体编进一个动态库?
来源: 互联网 发布时间:2015-09-01
本文导语: 由于这个项目是和别人一起开发,他们只负责提供目标文件给我们,然后由我们这边把我们编译的目标文件和他们的目标文件生成动态库提供给别人使用,但现在发现一个问题:如果我们直接用他们的libstatic.a生成动...
由于这个项目是和别人一起开发,他们只负责提供目标文件给我们,然后由我们这边把我们编译的目标文件和他们的目标文件生成动态库提供给别人使用,但现在发现一个问题:如果我们直接用他们的libstatic.a生成动态库libnormal.so,结果非常的不正常。
假设:现在有libstatic.a,还有xyz.c,libstatic.a会调用xyz.c中的内容。先把xyz.c编译成xyz.o,然后直接用命令gcc -shared -olibstaticbase.so -lstatic xyz.o生成libstaticbase.so,但是发现并不是libstatic.a中所有的内容都进入了libstaticbase.so。
但是如果把libstatic.a用ar x解压,然后用命令gcc -shared -olibnormal.so a.o b.o c.o ... xyz.o生成libnormal.so,结果非常正常,也就是说所有libstatic.a中的函数都进入了libnormal.so。libstaticbase.so和libnormal.so大小相差很大。
简而言之,如果我用静态库无法生成包含所有他的内容的动态库,但如果解压后用目标文件生成动态库,则一切正常。我想gcc应该有这样的选项,但是不知道是什么,请各位大虾赐教。
另外,我之所以要这么作,是因为我们要交叉编译到很多平台,如果我在Makefile里用*.o,那么以后Makefile的维护是个大问题,如果直接Makefile中用他们的.a文件,那么以后开发要简单的多。
在线等候!
假设:现在有libstatic.a,还有xyz.c,libstatic.a会调用xyz.c中的内容。先把xyz.c编译成xyz.o,然后直接用命令gcc -shared -olibstaticbase.so -lstatic xyz.o生成libstaticbase.so,但是发现并不是libstatic.a中所有的内容都进入了libstaticbase.so。
但是如果把libstatic.a用ar x解压,然后用命令gcc -shared -olibnormal.so a.o b.o c.o ... xyz.o生成libnormal.so,结果非常正常,也就是说所有libstatic.a中的函数都进入了libnormal.so。libstaticbase.so和libnormal.so大小相差很大。
简而言之,如果我用静态库无法生成包含所有他的内容的动态库,但如果解压后用目标文件生成动态库,则一切正常。我想gcc应该有这样的选项,但是不知道是什么,请各位大虾赐教。
另外,我之所以要这么作,是因为我们要交叉编译到很多平台,如果我在Makefile里用*.o,那么以后Makefile的维护是个大问题,如果直接Makefile中用他们的.a文件,那么以后开发要简单的多。
在线等候!
|
可以使用这样看看
gcc -shared -olibnormal.so `ar x libstatic.a` xyz.o
不过我记得编译成动态库的时候在将c文件编译为文件时候要指定-fPIC选项,
要不然可能会有时候出现问题,所以最好的办法是要求他们提供一个动态库
而不是提供一个静态库。
欢迎访问我的个人网站 www.linuxc.net
gcc -shared -olibnormal.so `ar x libstatic.a` xyz.o
不过我记得编译成动态库的时候在将c文件编译为文件时候要指定-fPIC选项,
要不然可能会有时候出现问题,所以最好的办法是要求他们提供一个动态库
而不是提供一个静态库。
欢迎访问我的个人网站 www.linuxc.net
|
呵呵,其实和ar x 出来所有的.o再编译是一样的。
不过,如果.o不是用-fPIC编译出来的话,很可能.so在使用中会有问题。
同意hoyt(hoyt(欢迎访问 www.linuxc.net)) 的看法,最好是让他们提供动态库。
不过,如果.o不是用-fPIC编译出来的话,很可能.so在使用中会有问题。
同意hoyt(hoyt(欢迎访问 www.linuxc.net)) 的看法,最好是让他们提供动态库。
|
use a perl script to get the .o list?
|
mark,学习
|
gz