如何管理共享库中的未定义符号答案

【问题标题】：how to manage undefined symbols in a shared library如何管理共享库中的未定义符号
【发布时间】：2013-01-28 05:25:26
【问题描述】：

我有一个未定义符号的共享库

JNI_CREATEJavaVM

有什么方法可以包含外部依赖或告诉编译器忽略该符号？

【问题讨论】：

编译器（和链接器）在您链接某些内容时不会检查已编译的共享库。如果您正在构建这个库，而不仅仅是拥有它，那么是的，您应该添加一个依赖项（通常是-l 选项到gcc）。

标签： c gcc shared-libraries

【解决方案1】：

是的，您可以告诉编译器忽略该符号。

来自man ld，

--unresolved-symbols=method

确定如何处理未解析的符号。方法有四个可能的值：

   ignore-all
       Do not report any unresolved symbols.

   report-all
       Report all unresolved symbols.  This is the default.

   ignore-in-object-files
       Report unresolved symbols that are contained in shared
       libraries, but ignore them if they come from regular object files.

   ignore-in-shared-libs
       Report unresolved symbols that come from regular object
       files, but ignore them if they come from shared libraries.

【讨论】：

【解决方案2】：

1) 我认为（开启心灵感应模式）您正在尝试构建 libdvm.so 并破解 Java NDK，它不会公开 JNI_CREATEJavaVM 函数。不要这样做。去谷歌搜索为什么不这样做，还有其他可能的解决方案。

2) 由于您的问题听起来像是“如何管理”，我将介绍我最喜欢的管理此类事情的方法——通过引入虚假的弱定义。让我们开始构建共享库，因为我们构建什么并不重要。考虑我们有一些带有代码的 undesym.c 文件：

int
main(void)
{
  JNI_CREATEJavaVM();
  return 0;
}

它会产生undefined reference to `JNI_CREATEJavaVM' 错误。

让我们添加链接模块 fakeone.c 与伪造的弱存根：

#include "assert.h"

int  __attribute__((weak))
JNI_CREATEJavaVM(void)
{
  assert(0 == "stub JNI_CREATEJavaVM is not for call");
  return 0;
}

现在一切正常，但在存根调用时会产生运行时断言

a.out: fakeone.c:6: JNI_CREATEJavaVM: Assertion `0 == "stub JNI_CREATEJavaVM is not for call"' failed

但为什么它很弱？因为考虑有人将它与真正的 JNI_CREATEJavaVM 代码联系起来。例如尝试 goodone.c

#include "stdio.h"

int
JNI_CREATEJavaVM(void)
{
  printf("JNI_CREATEJavaVM Ok\n");
  return 0;
}

并编译gcc undesym.c goodone.c fakeone.c 现在正确的定义会覆盖弱存根，你会得到正确的消息。

当然，你必须尽量避免这种技术，但它帮助了我好几次。

【讨论】：