Почему канадский крест используется для кросс--компиляции в Linux From Scratch?
POSIXly и при условии, что пути к файлам не содержат символов новой строки:
find. -type f -size -10000c | pax -rw /destination/
Здесь для файлов размером менее 10000 байт.
Некоторые реализации findимеют предикат -print0, а некоторые реализации pax— соответствующую опцию -0, которая приводит к тому, что список файлов ограничивается NUL -, что устраняет ограничение новой строки . упомянутый выше.
Во-первых, компьютер C не является чем-то, на чем вы можете практически компилировать. Это может быть встроенное устройство или даже просто рабочая машина, которую вы не хотите настраивать для компиляции.
Итак, у вас есть такая «никс-машина». Вы должны иметь возможность кросс-компиляции для него.
У вас есть машина для сборки. Это B. Это достаточно быстрая и мощная машина, но у нее нет компилятора. У него даже нет компилятора для сборки B, не говоря уже о компиляторе для C. Вы хотите использовать его для сборки вещей для C.
Как ты это понимаешь? Ну, вы поговорите с кем-то, у кого есть компилятор для B, в идеале тот, который перекрестно -компилирует в C напрямую. Затем вы загружаете его в B и используете для перекрестной -компиляции для вашей системы C.
Где они берут компилятор для B? Скорее всего, их система не идентична B. Как они начинают?
Все, что им действительно нужно, — это система А с компилятором, который компилирует программы для А.
Теперь этот компилятор, уже установленный на A, может быть не в состоянии создавать перекрестные -компиляторы. Это просто какой-то компилятор для языка (, например c ), предоставленный поставщиком или что-то в этом роде.
Что вам нужно, так это кросс-компилятор, который может компилировать двоичные файлы для B. Чтобы получить это, сначала вы берете свой компилятор A to A (ваш компилятор «поставщика» ),и скомпилируйте компилятор, поддерживающий перекрестную -компиляцию в B.
Затем вы берете этот компилятор и заставляете его скомпилировать перекрестный -компилятор, который компилирует из B в C.
Затем вы раздаете этот компилятор B to C человеку с компьютерами B и C.
...
Итак, это (и была )реальной проблемой. У вас есть машина Microsoft Windows с компилятором поставщика, или машина Solaris Unix, или машина macOS. В любом случае вы можете легко получить компилятор, но не кросс-компилятор. Эти поставщики мало заинтересованы в предоставлении вам кросс-компиляторов.
У вас нет компьютеров, которые есть у всех, кому вы поставляете инструменты, (B и C ). Таким образом, вы загружаетесь из своей «запертой» системы A до такой степени, что можете создавать и распространять полные наборы предварительно -встроенных инструментов для скачивания пользователями.
"Жесткое" требование состоит в том, что компьютер A должен иметь компилятор, который может компилировать перекрестный -компилятор из B в C; где и набор команд выполнения компилятора, и целевой набор инструкций компилятора чужды A.
Ответ Роаймы описывает логику, выдвинутую LFS. Я не уверен, что LFS дает хорошее объяснение трехсторонней компиляции "Canadian Cross".
Предположим, что машина A создает компилятор для машины B, который компилируется для машины C:
B и C обычно отличаются из-за ограничений машины C (да ). Например, разработчик может захотеть скомпилировать код для машины C, но C является очень ограниченным SBC или встроенным устройством и не может легко запустить собственный компилятор из-за ограничений ЦП и памяти. Поэтому разработчик использует свой гораздо более мощный настольный (компьютер B )для компиляции для C.
Чаще всего A и B различаются, но не из-за ограниченности ресурсов. Более распространенная причина часто заключается в том, что разработчик, который компилирует сам компилятор, отличается от разработчика, который компилирует окончательный код для C. Они часто не принадлежат к одной и той же организации.
Пример
Возьмите пакет ubuntu gcc -arm -linux -gnueabihf . Это поддерживается разработчиками Ubuntu Core. Этот пакет может загрузить любой, кто хочет скомпилировать программу для ARM на другой машине, например на машине AMD64. То есть любой может установить его на B для компиляции для C, и разработчики ядра Ubuntu не имеют никакого контроля над машинами B и C.
Теперь разработчики ядра Ubuntu компилируют gcc -arm -linux -gnueabihf для работы на amd64 arm64 и i386. Они не хотят и не нуждаются в трех сборочных машинах для сборки всех трех версий. Это потому, что машина a может иметь архитектуру, отличную от обеих машин B и C.