libc.so.6 和 libc.so 都存在于 rootfs 中

Question

我使用 Yocto 生成了我的 rootfs，然后发生了有线的事情，libc.so.6 和 libc.so 都存在于我的 rootfs 中（/usr/lib/libc.so 和 /lib/libc.so.6).但它们是不同的对象（不链接到单个对象），这将导致我使用 Yocto sdk 编译失败。

我知道我的 libc.so 与安装的 libsqlite3-dev 一起安装，但我不知道哪个配方真正生成 libc.so。

谁能帮帮我？

Answer 1

libc.so 是一个 linker 脚本 ，一个看起来像这样的小文本文件（为了便于阅读，此处换行）：

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP (
  /lib/x86_64-linux-gnu/libc.so.6
  /usr/lib/x86_64-linux-gnu/libc_nonshared.a
  AS_NEEDED ( /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 )
)

它指示 link 编辑器（ld，在构建期间 linking 时被调用，即，不是动态的 linker）寻找符号首先在 libc.so.6 中，一个共享对象，然后在 libc_nonshared.a 中，如果找不到它，最后在动态加载器中，ld-linux-x86-64.so.2）。这用于实现某些功能，例如在较新版本的 glibc 中，调用者敏感函数 pthread_atfork（必须静态 linked，因此它被放置在 libc_nonshared.a 而不是libc.so.6)。 linker 脚本通常由 gcc 或 g++ 命令隐式调用，但偶尔，您会看到包含 -lc 的命令行，并且那些选择 libc.so 脚本（当 link 动态运行时）。

linker 脚本仅在构建时使用。如果您的图像包含 libsqlite3-dev 等开发库，则有必要包含 libc6-dev（或任何提供 libc.so linker 脚本的包），因为 libsqlite3-dev 不适用于 link 没有 glibc 的新程序和共享对象。

libc.so.6 和 libc.so 都存在于 rootfs 中

Both libc.so.6 and libc.so exist in rootfs

glibc

libc

rootfs

yocto