【问题标题】:Is it possible to link to a shared library without access to the library itself?是否可以在不访问库本身的情况下链接到共享库?
【发布时间】:2017-12-14 08:06:47
【问题描述】:

我有共享库的头文件,但没有共享库或其源代码。

我还能针对这个库编译一些代码吗?

如果没有,共享库中包含哪些不在标头中的信息?

【问题讨论】:

  • 在 AIX 中是可能的:链接时,您可以使用 export-file 代替实际的库。我不知道在 GNU/Linux 中这样的事情是否可行

标签: linux linker shared-libraries ld elf


【解决方案1】:

我还能针对这个库编译一些代码吗?

编译:是的。链接:也许吧。

您可以创建一个虚拟库来链接。例如。如果标题包含:

int library_func(void*);

然后:

// dummy_lib.c
int library_func(void *p) { return 0; }

gcc -fPIC -shared -o libfoo.so dummy_lib.c

# Now you can use libfoo.so to link your program.

有一些陷阱:

  1. 真正的图书馆可能有SONAME 以外的libfoo.so(例如libfoo.so.2)。没有真正的libfoo,你就无法知道。
  2. 真正的库可以使用版本符号。如果您将程序链接到虚拟库,它将使用所有引用符号的默认版本,这现在可能是正确的,但将来可能会中断(如果/当使用新的和 不兼容你调用的任何符号的实现)。

【讨论】:

  • 我找到了一个更简单但不太健壮的解决方案:使用 clang 创建一个空库:echo "" | clang++ -shared -fPIC -x c++ - -o libfoo.so 并告诉clang / ld 在链接时忽略未解析的符号:-Wl,--unresolved-symbols=ignore-in-object-files。
【解决方案2】:

是的。您可以为它们声明指向函数的指针,然后调用dlopen 和dlsym,然后就可以了。但是,试图以某种方式构建一个可执行或共享库,就好像您已经链接到该库一样是有风险的。有关详细信息,请参阅 Employed Russian 的回答。

当然,您将需要这些库本身来运行代码。

但是,请注意,并非所有“共享库”都只是共享库。在某些情况下,除了运行时的.so 之外,还有一个.a 文件在链接时用于提供一些静态链接代码。这并不常见。

【讨论】:

  • “链接器不会根据库的内容更改任何内容。” -- 当考虑版本符号时,这是非常错误的。
  • 当您打算使用 dlopen 和 dlsym 时,我认为版本化符号不会对这种形式产生奇怪的影响。我会澄清的。
  • dlsym 和版本化符号以更加令人困惑(可以说是损坏)的方式交互。 sourceware.org/bugzilla/show_bug.cgi?id=14932
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-11-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-08
  • 1970-01-01
相关资源
最近更新 更多