[devel] использование сборочных возможностей RPM для кросс-компиляции/сборки (прежде: I: x86_64 update)

Ildar Mulyukov =?iso-8859-1?q?ildar_=CE=C1_altlinux=2Eru?=
Вт Июл 18 12:31:07 MSD 2006


Здравствуйте,

Есть идея, несколько мыслей и вопросы. Всё довольно не систематично, я  
предупредил!

Постановка задачи: хочется создать среду для прозрачной кросс-сборки  
_некоторых_ программ (в пакетах) для "чуждой" платформы (в моём случае  
это XScale-linux (familiar).

Предпосылки: у rpm есть ключ --target, который может прозрачно  
передаваться макросу %make_build

Предположительно, как это можно сделать: Подпилить rpm-build, чтобы для  
нужных архитектур находились макросы и использовались нужные binutils.  
Создать пакет(ы) rpm-build-cross-{arch,...} с зависимостями на соотв.  
кросс-средства. Также хорошо бы создать информационную страничку (wiki  
на freesource.info?) для сбора информации о предмете.

Поиск: поворошив архивы альтлинукса на тему кросс-компиляции, наткнулся  
на след. письмо -  
http://lists.altlinux.org/pipermail/devel/2005-February/018012.html

Судя по нему, для замысла есть непреодолимые трудности (?) Если  
возможно, хотелось бы получить комментарии (в т.ч. от mouse@)

> [devel] I: x86_64 update
> Anton D. Kachalov mouse на altlinux.org
> Чт Фев 3 12:27:33 MSK 2005
> 
> On Thu, Feb 03, 2005 at 11:44:45AM +0300, Vitaly Lipatov wrote:
> > > именно только на x86_64 , кросскомпилинг страшная и невсегда
> > > работающая штука
> > Не вижу объективных причин. Мне кажется, как к нему относишься,
> > так он и работает. А основная причина может в том, что мысли о
> > том, что в Сизифе должен быть кросскомпилятор (кроме mingw) -
> > нет.
> кросс x86_64 (gcc3.3, а 3.4 я не пробовал) оооочень крив. Там нужно
> было жуткое кол-во костылей вставлять, чтобы что-то собирать.
> С ARM и MIPS такого секса я не ощущал, как с кроссом x86_64.
> Нативная сборка всегда лучше, тем более, когда есть вычислительное
> мощности. Одна из причин - это то, что хост среда отличается от
> таргета.
> Представляем себе некую прогу, которая говорит uname -m и
> ориентируется на это.
плохие проги!

> А ещё есть проги (кривые), которые любят сначала собрать прогу, а  
> потом этой прогой заюзать для дальнейшей сборки.
Бывает, но не так часто.

> Опять же, кроссовые либы живут не в /usr/lib/, а в /usr/arch/usr/lib.
Этот вопрос рано или поздно надо решать. Как решать - по этому поводу  
надо собрать информацию и положить в wiki

> И опять вспоминаем какие-нить проги, которые тож жёстко к этому
> привязываются. А ещё...
хорошо, я понимаю автора (mouse), который исходил из самого общего  
случая. Думаю, что программ, для которых изначально предусмотрена  
кросс-платформенная сборка, эти проблемы не касаются. (я, в частности,  
хочу собрать насколько таких программ)

> И самое главное - как вы себе представляете сборку пакетов под другу
> архитектуру кроссом из того же спека? (С учётом устанавливаемых  
> пакетов в собираемую среду).
Вот тут мне не понятно, в чём трудность. Есть предположения? Конечно, с  
текущей версией rpm-build это невозможно.

> И ещё, тот же rpm не позволит поставить пакет другой архитектуры,  
> если ему не написать, что i586 совместим с x86_64 - бред
> же.
А.. вот это надо как-то обойти. Возможно, имеет смысл отдельное дерево  
(/usr/arch?) со своим %archprefix/var/lib/rpm/Packages и плясками c
rpm-build. Тут надо крепко подумать и воплотить в rpm-%version.src.rpm

> Т.ч.наличие кросса avr и mingw - всего-лишь необходимость в сборке  
> под девайсы (avr), на которых просто нереально что-либо собирать :))
> а mingw я тож пользуюсь, но пакеты ж не собираю...и вроде пока никто  
> не устраивает (и не собирался вроде) отдельного cygwin-репозитария.
Ну почему же? Мне было бы интересно.

Всё написанное предлагается к обсуждению. Если это неуместно, я готов  
смиренно перейти в другой список рассылки.

С уважением, Ильдар.
--
Ildar  Mulyukov,
   free SW designer/programmer/packager
=========================================
email: ildar на altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================



Подробная информация о списке рассылки Devel