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

Это работает только в bash

bash$ paste <(cut -f1 file) <(cut -f2- file |
        sed -r '1b;        # if title line then skip to end
        s#\t#\n#g          # seperate line to multi-line
        s#.*[^0].*#1#Mg    # apply multi-line operation 
        s#\n#\t#g' )       # turn to one line

        a       b       c
A       1       1       0
B       0       1       1
C       1       1       1
D       1       0       1
1
15.12.2016, 00:04
2 ответа

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

2
27.01.2020, 23:34

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

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

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

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

0
27.01.2020, 23:34

Теги

Похожие вопросы