Блог

Я использовал Yocto для генерации своих rootfs, и произошла связанная вещь, как libc.so.6, так и libc.so существуют в моих корневых файлах (/usr/lib/libc.so и /lib / libc.so.6). Но это разные объекты (не связанные с одним объектом), что приведет к сбою моей компиляции с помощью Yocto sdk.

Я знаю свой libc.so устанавливается вместе с установленным libsqlite3-dev, но я не знаю, какой рецепт это действительно генерирует libc.so.

Кто-нибудь может мне помочь?

libc.so это скрипт компоновщика, небольшой текстовый файл, который выглядит следующим образом (строки перенесены сюда для удобства чтения):

 /* 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 )
)
  

Он инструктирует редактор ссылок ( ld , который вызывается при компоновке во время сборки, т. Е. не динамический компоновщик) сначала искать символы в libc.so.6 совместно используемом объекте, затем в libc_nonshared.a , если он не может его найти, и, наконец, в динамическом загрузчике, ld-linux-x86-64.so.2 ). Это используется для реализации определенных функций, например, в более новых версиях glibc, функции, определяющей вызывающий объект pthread_atfork (которая должна быть связана статически, поэтому она помещается в libc_nonshared.a , а не libc.so.6 в). Сценарий компоновщика обычно вызывается неявно командами gcc или g , но иногда вы увидите командные строки, которые содержат -lc , и те подхватывают libc.so скрипт (при динамическом связывании).

Скрипт компоновщика используется только во время сборки. Если ваш образ содержит библиотеки разработки, такие как libsqlite3-dev , его необходимо включить libc6-dev (или как там называется пакет, предоставляющий libc.so скрипт компоновщика), потому что libsqlite3-dev его нельзя использовать для связывания новых программ и общих объектов без glibc.