Flip Linux
  1. Flip Linux
  3. Почему LFS и CLFS меняют путь, используемый для поиска динамического компоновщика?
Intereting Posts
Как сделать `head` и` tail` на вход с нулевым ограничением в bash? Понимание использования ln Шифрование диска с помощью ecryptfs – полный диск заставляя прокси-трафик маршрутизировать через специальный интерфейс ключа 3G Не могли бы вы объяснить, почему эта команда (pgrep -d ',' -f cmdStr | top -c -p) не работает? Как исправить ошибку «Kernel panic – не синхронизация: VFS: невозможно монтировать root fs на неизвестном блоке» и «данные LZMA повреждены» Сколько пространства подкачки требуется Solaris 11.3 для запуска компилятора? Команда, действующая по-разному в файле bash_profile vs terminal systemd-modules-load ошибки печати при загрузке встроенных модулей ядра Какова фактическая цель опции -X GNU grep и почему она недокументирована? Команда источника подачи с трубой Как получить точку монтирования файловой системы, содержащую данный файл Как один порт USB может сообщать о двух разных идентификаторах шины? Samba: Совместное использование нескольких папок без дубликатов? где можно найти задержку на диске с помощью iostat (await, svctm,% util)?

Почему LFS и CLFS меняют путь, используемый для поиска динамического компоновщика?

Как LFS, так и CLFS применяют исправления к источнику GCC перед их созданием.

Патч CLFS немного более активен, чем патчи LFS, но то, что у них общего, – это изменение пути, используемого для поиска динамического компоновщика. В этом случае он переместится в место, где будет построена новая версия glibc.

Поскольку, по крайней мере, в случае с CLFS вы создаете перекрестную цепочку инструментов и, по-видимому, вы не можете запустить что-либо, построенное с помощью этой цепочки на вашей машине сборки, какая разница, где GCC имеет программы для поиска динамического компоновщика. Разве это не операционная работа, которая никогда не произойдет? Кроме того, если вы построили двоичный файл с этим GCC, тот, который требует общих библиотек и попытался запустить его на вашей цели, не будет ли путь к dyanmic linker неправильным?

Дополнительно (C) LFS вы изменяете STANDARD_STARTFILE_PREFIX_X чтобы указать на $INSTALL_PATH/tools/lib/ . Разве эти пути, по-видимому, не проверялись бы, если / если вы указываете --with-sysroot ? После создания GCC с --with-sysroot если я проверю --preint-search-dirs я не вижу, чтобы он смотрел в любом пути, кроме ссылок на префикс или --with-sysroot .

Страницы, которые вы связали, предназначены для создания временной цепочки инструментов, которая затем используется для построения конечной системы в главе 6 LFS. GCC в главе 6 компилируется без каких-либо патчей. Патчи во временной цепочке инструментов существуют только там, чтобы позволить дальнейшую компиляцию пакетов независимо от того, какие инструменты использует хост-система.

(C) LFS очень сильно пытается создать систему Linux с минимальными связями с машиной сборки. В результате некоторые из этапов могут казаться ненужными, излишними или изобретенными. Вот (подмножество) процесса CLFS, в котором рассматривается основной вопрос:

  1. Ch5: Cross binutils
  2. Ch5: 1-й проход крест GCC
  3. Ch5: Glibc (который может использоваться как кросс-компилятором, так и целевым), устанавливается с префиксом /tools
  4. Ch5: 2-й проход cross gcc. Патч dynamic-linker-path-patch применяется здесь, чтобы указать на /tools , который является символической $CLFS/tools на $CLFS/tools где $ CLFS является корнем файловой системы цели.
  5. Ch6: Используйте 2-й проход cross gcc, чтобы создать кучу новых инструментов, которые будут родными для цели, к ним относится версия gcc для запуска native на целевой. Наглядно отсутствует в этом списке другая копия glibc. Это не требуется, потому что тот, который был построен ранее, сейчас прекрасен.
  6. Ch10: Boot / chroot в целевую систему, которая теперь имеет /tools в том же месте, что и ваша машина сборки. Это позволяет ранее создавать инструменты (как родные) для доступа к динамическому компоновщику. Теперь вы снова сделаете glibc, но на этот раз он войдет в стандарт /usr (вместо /tools/usr )

Корень вопроса касался динамического пути компоновщика и того факта, что он появляется относительно машины сборки. Ответ в основном заключается в том, что OP (я) не думал о том, как была символическая ссылка между / tools и ${CLFS}/tools и что патч был применен для создания / инструментов корневого пути к компоновщику.

У меня нет ответа на вопрос STANDARD_STARTFILE_PREFIX_X .