|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Victor Wagner 2:5020/400 13 Oct 2004 10:05:48
To : Sergey_Afonin
Subject : Re: компиляция для чужой системы?
--------------------------------------------------------------------------------
Sergey Y. Afonin <Sergey_Afonin@p13.f29.n5057.z2.fidonet.org> wrote:
SYA> Innocenti Maresin wrote:
>> Т.е. на рабочей станции я хочу собрать нечто,
>> предназначенное для работы прежде всего, или даже исключительно
>> на какой-то другой "целевой" машине, тоже с Linux-системой,
>> но с заметно другим процессором, иным набором софта и т.д.
SYA> Можно на рабочей станции копию нужной системы в chroot загнать.
SYA> Таких наборов можно сделать много, вопрос только в месте на диске.
ТЫ хорошо подумал? Сильно ли тебе поможет chroot если тебе нужна сборка
для другого целевого процессора?
Вообще chroot это какой-то buzzword в современном linux-овом мире. Вроде
как "объектно-ориентированное программирование" или тезис о вредности
suid-бита. Все кто не врубается в ситуацию, суют его куда ни попадя.
Hа самом деле у IM есть две разные задачи.
1. Компиляция под другой целевой процессор. Это называется
cross-компиляцией. Для этой цели нужно собрать специальную версию gcc,
которая будет генерировать код для другого процессора. И подложить ей
некоторые библиотеки от той системы.
Достигается это очень просто указанием параметра --target= для gcc-шного
configure. Естественно, что нужно сначала выяснить как называется нужный
target.
После этого gcc начинает искать заголовочные файлы в
${prefix}/${target}/include, а библиотеки в ${prefix}/${target}/lib,
где prefix обычно /usr или /usr/local.
Что касается "другого набора софта", то обычно он собранной софтине по
барабану. Важно чтобы был нужный. А это достигается сборкой софтины в
пакет с аккуратным прописыванием зависимостей.
Бывают, конечно, странные случаи, когда например там стоит старая glibc
и апгрейдить её ни в коем случае нельзя, так как от этого сломается
какой-нибудь Oracle. В случае кросс-компиляции тут все просто -
библиотеки и хидеры все равно берутся из отдельного места.
А вот если ты собираешь под такой же процессор родным для твоей системы
gcc, то тут действительно может оказаться удобным chroot. Hе
обязательным, поскольку gcc достаточно гибок и ему можно объяснить
откуда библиотеки брать, а откуда не брать, но удобным.
SYA> --
SYA> С уважением, Сергей Афонин.
SYA> asy*kraft-s.ru
--
Порой ложь так тесно сливается с правдой, что оставшейся щелке
тяжело жить.
--- С.Е. Лец
--- ifmail v.2.15dev5.3
* Origin: Free Net of Leninsky,45 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
