了解链接器错误：命令行中缺少 DSO

Question

所以最近，我一直试图更好地理解共享库的符号解析是如何工作的。我创建了 2 个共享对象（libfoo 和 libbar）和 1 个可执行文件（test）。考虑以下一组程序：

foo.c

#include <stdio.h>
void foo()
{
    puts(__func__);
}

bar.c

#include <stdio.h>
extern void foo(void);
void bar()
{
    puts(__func__);
    foo();
}

test.c

#include <stdio.h>
extern void foo(void);
extern void bar(void);
int main()
{
    puts(__func__);
    foo();
    bar();
    return 0;
}

libbar 依赖于libfoo，而test 依赖于libfoo 和libbar：

gcc -c -Wall -fPIC foo.c bar.c
gcc -shared -o libfoo.so foo.o
gcc -shared -o libbar.so bar.o -L. -lfoo

现在在构建测试时，我故意不提供对 libfoo 的直接依赖：

cheshar@editsb:~/2-test $ gcc -o test test.o -L. -lbar -Wl,-rpath-link=.
    /usr/bin/ld: test.o: undefined reference to symbol 'foo'
    ./libfoo.so: error adding symbols: DSO missing from command line
    collect2: error: ld returned 1 exit status

cheshar@editsb:~/2-test $ ldd libbar.so
    linux-vdso.so.1 =>  (0x00007ffe27bf7000)
    libfoo.so => not found
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7d203e0000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f7d209ac000)

正如我们所见，test 需要符号 foo 并依赖于 libbar，而 libbar 又依赖于 libfoo 并具有所需的符号。所以我的问题是为什么链接器不能解析符号？是不是应该可以扫描所有的依赖和链接来生成可执行文件？

Answer 1

为了链接您的可执行文件，您需要在命令行中添加-lfoo。 命令行传递的库和 rpath “传递”的库不会有相同的处理。通过命令行传递的那些将由open_input_bfds 处理，而由rpath“传递”的onse 将由ldemul_after_open 处理，对于x86 来说是gldelf_x86_64_after_open。
您看到的错误来自bfd_elf_link_add_symbols，它是 gnu 的选择。在这个函数中你有这个代码：

      /* A symbol from a library loaded via DT_NEEDED of some
     other library is referenced by a regular object.
     Add a DT_NEEDED entry for it.  Issue an error if
     --no-add-needed is used and the reference was not
     a weak one.  */
      if (old_bfd != NULL
      && (elf_dyn_lib_class (abfd) & DYN_NO_NEEDED) != 0)
    {
      _bfd_error_handler
        /* xgettext:c-format */
        (_("%B: undefined reference to symbol '%s'"),
         old_bfd, name);
      bfd_set_error (bfd_error_missing_dso);
      goto error_free_vers;
    }

从更改日志中：

• elflink.c (elf_link_add_object_symbols)：检查 DYN_AS_NEEDED， DYN_DT_NEEDED 和 DYN_NO_NEEDED 位查看是否有 DT_NEEDED 需要输入。如果需要 DT_NEEDED 条目，则发出错误 对于标记为 DYN_NO_NEEDED 的文件。

事实上 libfoo.so 将被 libbar.so 标记为需要，而不是 test.o 。 gldelf_x86_64_search_needed 中将创建一个 dt_needed 结构。

lang_process
-> ldemul_after_open ()=gldelf_x86_64_after_open
-->gldelf_x86_64_search_needed (dt_needed created)
--->gldelf_x86_64_try_needed
---->bfd_elf_link_add_symbols
----->elf_link_add_object_symbols ( the error )

另外，如果你不想添加-lm，你可以在test.c extern void __attribute__((weak)) foo(void); 的foo 中添加weak 属性，这样链接器就不会再抱怨了。如前所述，这是一个 gnu 选择（我在评论、文档或更改日志中没有找到任何解释）。但仅在我看来，这是一种避免选择错误符号的保护措施。