我团队项目的开发方式是从我们所有的.o
目标文件中为我们的应用程序生成一个共享对象库。 我的任务(希望它足够具体,但也足够用于其他人!)是仅链接自上次创build可执行文件以来发生更改的对象文件。 例如,下面是我用来构build.so的命令行:
g++34 -shared -rdynamic -m64 -Wl,-rpath,'$ORIGIN' MyObject1.o MyObject2.o MyObject3.o MyObject4.o -o libMySharedLibrary.so
哪个按预期工作! :)我的目标是能够从现在开始只链接改变的目标文件,以加快并发链接过程。 示例命令是:
g++34 -shared -rdynamic -m64 -Wl,-rpath,'$ORIGIN' MyObject1.o MyObject3.o -o libMySharedLibrary.so
哪个会更新libMySharedLibrary.so
与新的对象文件,同时还保留在libMySharedLibrary.so
较旧的对象文件。 实际上,当我使用上面的命令生成libMySharedLibrary.so
时,文件大小要小于包含所有目标文件的文件大小,所以我几乎可以确定上述命令没有按照我的要求进行。
通过我的研究,我发现链接器有一个-i
选项,它与-r
选项相同,它似乎只是把所有的目标文件合并成一个大的目标文件。 不幸的是,这似乎并不是我想要的。
简而言之,我只想在初始链接之后链接已更改的对象文件,从而为将来的链接加快链接过程。 有没有办法做到这一点?
编辑:我用-i/-r
试过的一个例子:
示例命令: g++34 -Wl,-r -nostdlib -rdynamic -m64 -Wl,-rpath,'$ORIGIN' MyObject1.o MyObject2.o MyObject3.o MyObject4.o -o AllMyObjects.o
我不得不添加-nostdlib
标签来阻止它大喊大叫需要它,并删除了-shared
因为共享对象不允许与-r
标签。
这个命令似乎将我所有的.o文件都压缩成一个大的.o文件。 所以,如果我只能从这里更新.o文件,只用更改后的.o文件,那就太好了。 在最初创buildAllMyObjects.o之后,我尝试了这个命令: g++34 -Wl,-r -nostdlib -rdynamic -m64 -Wl,-rpath,'$ORIGIN' MyObject1.o MyObject3.o -o AllMyObjects.o
,但它也会创build一个小得多的(文件大小明智的) AllMyObjects.o
,所以我假设它不可能拥有所有的对象文件。 我觉得这是我可能犯的一个小错误。 任何人有任何build议? 提前致谢。
看起来你是对的 – -shared
和不共同工作。 我对你的旧GCC版本持怀疑态度,但即使在Ubuntu 10.10上,我也可以看到:
$ ld -shared -r /usr/bin/ld.bfd.real: -r and -shared may not be used together
不幸的是,如果你绝对需要共享对象,那就意味着你已经到了死胡同的地步。 binutils链接器根本没有实现它。
如果静态库是您的选择,它们只是简单的归档文件,可以使用ar
实用程序轻松进行操作。
否则,你将不得不看看不同的连接器或编译器套件。 尽管如此,我不能保证你会发现这个功能。
使用归档/静态库之后,您可以对获得的行为进行排序,但初始链接仍然需要相同的时间。
使用档案文件:
# Initially create the archive ar r libmylib.a <all object files> # Create your shared object (re-use this line after libmylib.a is updated) g++ -shared -rdynamic -m64 -Wl,-rpath,'$ORIGIN' libmylib.a -o libmylib.so # Update the archive file ar r libmylib.a updated1.o updated2.o
正如我所说的那样,实际上将链接到.so
的时间仍然与以前一样。