我正在尝试打包一些本机库以包含在java natives .jar中。目前，我们的目标是32位和64位Linux和Windows，即将推出macosx（总共会产生6种变体）。此外，如果我们可以将几个小型库汇总成一个大型库，我们会遇到一些命名问题。
我的目标是转换
my_library.so dependencyA-55.so dependencyB-50.so
到
my_library_without_dependencies.so
我有dependencyA和dependencyB的完整（C和C ++）来源;但是，我宁愿不干涉他们的编译，因为它非常复杂（ffmpeg）。我试图使用gcc 4.6（ubuntu 12.04 64位）来解决这个问题，如果找到解决方案，理想情况下应该适用于64位和32位Linux，以及64位和32位Windows体系结构（交叉） - 通过mingw32编译。
是否有任何神奇的链接器选项组合会导致GCC将依赖项包含在单个最终共享库中？我专注于the linker options没有成功，相关的SO问题没有解决这个用例。
答案 0 :(得分：1)
不可能。
共享对象已经是链接器的产品，并且已经准备好执行。
相反，你可以创建静态库为“dependencyA.a”和“dependencyB.a” （因为你有源代码）并在创建“my_library.so”时使用“--whole-archive”链接器开关