每个未定义的符号都与它来自的库名称相关联吗? [英] Is every undefined symbol associated with the library name it comes from?

问题描述

让我们说libA.so依赖于libB.so，libC.so，libD.so.在未定义的符号和所需的库名称之间是否存在映射:

Let's say that libA.so depends on libB.so, libC.so, libD.so. Is there a mapping between the undefined symbols and the required library names:

undefined_symbol_1 comes from libB.so
undefined_symbol_2 comes from libC.so
undefined_symbol_3 comes from libC.so
undefined_symbol_4 comes from libC.so
undefined_symbol_5 comes from libD.so

还是将它们单独保存:

Undefined symbols: undefined_symbol_1, undefined_symbol_2, undefined_symbol_3, undefined_symbol_4, undefined_symbol_5;
Required libraries: "libB.so", "libC.so", "libD.so";

系统:ubuntu

工具:g ++

推荐答案

在Linux/elf格式中没有这样的映射.未解析的符号和所需的库不相关.

There is no such mapping in Linux / elf format. The unresolved symbols and required libraries are not dependent.

实际上，您可以预加载(使用LD_PRELOAD)另一个可解析任何未解析符号的库.此方法通常用于用另一个堆实现替换libc malloc和朋友，而无需重新编译可执行文件.

In fact, you can pre-load (using LD_PRELOAD) another library that resolves any of the unresolved symbols. This method is often used to replace libc malloc and friends with another heap implementation without recompiling the executable.

解析符号时，运行时链接程序会按加载顺序浏览已加载的可执行文件和库的列表，并选择第一个用于解析符号的文件.

When resolving a symbol the run-time linker walks a list of loaded executables and libraries in the order they were loaded and the first one to resolve the symbol is picked.

建议阅读:如何由Ulrich Drepper编写共享库.

这篇关于每个未定义的符号都与它来自的库名称相关联吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！