Вопрос

Мой родной gcc говорит, что его триплет следующий.

> gcc -dumpmachine
x86_64-suse-linux

Где cpu-vendor-os - это соответственно x86_64, suse, linux.Последнее означает, что используется glibs(?).Когда я выполняю кросс-компиляцию системы на основе busybux, триплет компилятора представляет собой что-то вроде avr32-linux-uclibc, где os - "linux-uclibc", что означает, что используется uclibc.

Разница между 'linux-glibc' и 'linux-uclibc' заключается (AFAIU) в поведении collect2 и содержимом libgcc.a.Либо glibc, либо uclibs автоматически связаны с целевым двоичным файлом.

Вопрос в том, каким образом ядро Linux было скомпилировано теми же компиляторами?Как только ядро запускается на "голом металле", оно не должно быть связано с каким-либо видом libc в пространстве пользователя и должно использовать соответствующий libgcc.a

Это было полезно?

Решение

у gcc есть всевозможные опции для управления тем, как это работает.Вот несколько важных из них:

  • -nostdlib опустить ссылки на стандартные библиотеки и код запуска
  • -nostdinc чтобы исключить поиск заголовочных файлов в стандартных расположениях.
  • -ffreestanding для компиляции для автономной среды (например, ядра)

Вам также не нужно использовать gcc для связывания.Вы можете вызвать компоновщик напрямую, снабдить его своей собственной картой компоновщика, объектным кодом запуска и всем остальным, что вам нужно.

Сборка ядра Linux, похоже, по произвольным причинам не используется -ffreestanding Тем не менее, он управляет этапом связывания и гарантирует, что ядро будет связано без использования какого-либо пользовательского кода.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top