比方说，我们正在构建一个需要链接到2个外部静态库B中的共享库A和C.你要做的是libB.a和libc.a，用自己的头文件一起。
这里有一个简单的Android.mk为力霸：
LOCAL_LDLIBS := ../external/libB.a ../external/libC.a
include $(BUILD_SHARED_LIBRARY)
据我所知，链接的作品共享库的方法是：
- 抢B和C的所有目标文件
- 剥离出对象文件A不参考
- 解决B和C的引用
因为B和C互相调用，特别是他们称之为得到了在步骤2中剥离出来，因为一个没打电话给他们的功能这给了链接错误。
如果我们建立了静态库自己，那么它只是与LOCAL_WHOLE_STATIC_LIBRARIES更换LOCAL_STATIC_LIBRARIES的问题，防止代码剥离（以代码大小为代价）。 引擎盖下，它通过--whole归档的连接。
由于我们没有建立B和C（甚至不具有源重建它们），有什么选择？
- 手动引用缺少的功能，从A，使他们没有得到剥离
- 弄清楚如何--whole归档传给连接器的外部静态库
- 使用PREBUILT_STATIC_LIBRARY（看到它提到，但从来没有使用过它，并根据文档它听起来并不适用于这种情况）
- 构建可执行代替共享库（这不会破坏码相同的方式）
- 移动/重命名外部库欺骗NDK编译系统，以为他们是我的，让我可以将它们添加到LOCAL_WHOLE_STATIC_LIBRARIES。
我已经使用选项1，因为它是工作的第一件事情，但显然它不是很大。 我问是否有更好的解决方案。
在回答这个问题（ 链接问题，当与Android NDK预置的静态和共享库 ）使我想知道如果我需要重新评估我的构建设置（共享库链接到外部静态库）。 我无法评论那里，所以我问我自己的问题在这里。
答案可以发现如何处理使用的binutils链接静态库之间的依赖关系递归？ 。
LOCAL_LDLIBS := -L ../external/ -lB -lC -lB
我拿着两库NDK样本，并取得了微小证明该技术在GitHub上 。
更新（2017年）：2012年以来，NDK的规则变得更加严格，而现在它会抱怨说， LOCAL_LDLIBS包含非系统库：
Android的NDK：警告：Android.module：非系统库中的连接标志：-La -lb
Android的NDK：这很可能导致不正确的版本。 尝试使用LOCAL_STATIC_LIBRARIES
Android的NDK：或LOCAL_SHARED_LIBRARIES改为列出的库的依赖关系
Android的NDK：当前模块
这仅仅是一个警告，所以你可以忽略它。
或之后加空格-l智取NDK保护：
LOCAL_LDLIBS := -L ../external/ -l B -l C -l B
另外，您也可以使用
LOCAL_LDLIBS += -L ../external -Wl,--start-group -l B -l C -Wl,--end-group
如果所涉及的库不预建的，你不需要去猜测他们的位置（使用Android NDK工作室整合时可能会尤为棘手）。 使用
LOCAL_LDLIBS := -L $(TARGET_OUT) …
存在的另一种方法，不使用“递归”链接。 但它涉及的迭代。 首先，尝试建立自己的共享库的常规方式。 当这种失败，未解决的符号，复制所有这些符号到剪贴板，并粘贴你的Android.mk。 比方说，这些符号extBa ， extBb和extBc （ 在上述情况下，我认为，之所以在链路出现故障的libC的一些对象没有发现在某处libB定义这些符号，那是 ）。 你现在需要的，加
LOCAL_LDFLAGS += -Wl,-u'extBa' -Wl,-u'extBb' -Wl,-u'extBc'
您可以进行下一个步骤，有这一切捆绑的libC：
LOCAL_EXPORT_LDFLAGS += -Wl,-u'extBa' -Wl,-u'extBb' -Wl,-u'extBc'
现在使用的libC任何共享库不会错过这些符号。
