roboforum.ru

Виталий писал(а):2. Почему-то в Linux сообществе принято считать что лучший документ на систему - ее код. Что из этого получается думаю всем известно. Куча патчей и переписка в багтрекерах.

И это нормально! Потому, что сама система ничего не стоит. Оплачиваете вы ее своим временем, или деньгами тем людям которые профессионально занимаются ее поддержкой.

Это "нормально" с философской точки зрения. С технической точки зрения - это бред.

Угу, копался в исходниках. Это было что-то. Во-первых они не читаемые - вероятно специально шифруются от злодеев и негодяев. Если ты не гик с 20-летним стажем, то результата такое чтение не принесет. Во-вторых они очень мудреные, простейшие операции завуалированы через сотню макросов и десяток функций. Ну мне ответят на это - "ну и что? Не хочешь не разбирайся". Только вот сейчас уже наглядно видно к чему приводит уплотнение Си кода. Взгляните на GTK и Gnome - они ужасны по виду и баг на баге сидит. Немножно лучше дело обстоит с KDE, догадались на C++ писать.

Взгляните на GTK и Gnome - они ужасны по виду и баг на баге сидит. Немножно лучше дело обстоит с KDE

Хотите похоливарить? Я всю жизнь пользовался и пользуюсь гномом, а от вида кед мне хочется показать всем, что я кушал
Можно ну хоть один баг озвучить именно НАЙДЕНЫЙ ВАМИ глядя на гуй, а не в багзиллу гнома

setar писал(а):

Michael_K писал(а):По поводу "кросс-компиляторов".... GCC из-под винды.

Я написал не просто так.
Кросс компилятор нужен для сборки ядра, и базовых пакетов.
Включая нативный компилятор (если он требуется).
ну и все это : "- библиотеки-драйвера (файловая система, коммуникации, графика)" тоже собирается кросс компилятором.

Может быть непонятно прозвучало - естественно, я писал про GCC _для_АРМ_ - это и есть кросс-компилятор.

Это не одно и то же.
Разница примерно как между транзистором и ПЛИС.

Что не одно и то же?

Видимо gcc, который под arm'ом запускается и компилирует для arm'а, и кросс-компилятор gcc компилирующий на pc под arm...

Ну, это-то, конечно, не одно и то же.
Первое - ни разу не кросс-компилятор
И непонятно, зачем оно вообще нужно.

Ну, к примеру, народ под DIR-320 для DIR-320 компилирует на любителя конечно, как впрочем и кросс-компиляция...

Сетар говорил конкретно: "тебе нужен кросс-компилятор". Я ответил: "он у меня есть и работает".

Он также сказал, что если вдруг потребуется, кросс-компилятором можно собрать нативный компилятор. Я это тоже понимаю (хотя не очень понимаю нафига бы оно мне понадобилось).

Что "это", которое "не одно и то же" - я не понимаю. И не оно и то же с чем? Загадка...

Добавлено спустя 4 минуты 28 секунд:

=DeaD= писал(а):Ну, к примеру, народ под DIR-320 для DIR-320 компилирует

И каков глубокий смысл этой процедуры? замусорить и без того ущербную память роутера исходниками и компиляторами или подольше ждать?

я писал про GCC _для_АРМ_ - это и есть кросс- компилятор.

Ну, это-то, конечно, не одно и то же.

Вы лучший
gcc для arm не есть кросс-компилятор.

Gcc запускающийся на PC и генерирующий исполняемый код для ARM - это именно кросс-компилятор. Правильно используйте термины, если хотите, чтобы вас понимали.

http://ru.wikipedia.org/wiki/%D0%9A%D1% ... 0%BE%D1%80

Кросс-компиля́тор (англ. cross compiler) — компилятор, производящий исполняемый код для платформы, отличной от той, на которой исполняется сам кросс-компилятор.

И каков глубокий смысл этой процедуры? замусорить и без того ущербную память роутера исходниками и компиляторами или подольше ждать?

Как ни странно смысл есть (для линукса, не для одиночных самостоятельных бинарников)
В двух словах это корректное окружение для сборки пакетов.
Не все пакеты можно собрать кросс компилятором, иногда в ходе сборки используется запуск только что собранного бинарника для выяснения параметров для сборки следующего. Поскольку выполнить код например ARM на pc в лоб (без применения эмуляторов) невозможно, то такой пакет собран не будет.
С эмулятором все хорошо, кроме производительности
Современный проц на одном ядре делает эмуляцию ARM7 примерно в 2 раза медленнее оригинала - вот и прямой смысл использовать "нативную" (на родном железе) сборку.
Исходный код держать на устройстве не нужно, сборка ведется обычно при загрузке системы с емким и быстрым сетевым корнем по NFS

Я это понимаю, но на самом деле мне кажется, что таких ситуаций достаточно немного. Думаю, что большая часть случаев (если не все вообще) может быть собрана и в кросс-среде.

(Как-то же портировали линукс на арм в самый первый раз )

У меня-то лично есть ощущение, что основные причины использования нативных компиляторов в том, что 1. "лень разбираться" и 2. "лучше не рисковать".

запуск только что собранного бинарника для выяснения параметров для сборки следующего.

Вы же сами понимаете, что это извращение, хотя я не сомневаюсь, что через эту ж... все и ходят. Только потому, что этот путь наиболее автоматизирован.

Это наверняка имеет глубокий смысл для осей, которые запускают, например, на заранее неизвестном железе (фиг знает из чего собранный комп). Или если пересобирается не все с нуля, а только какой-то кусок (например, мы хотим собрать только ГУЙ, но надо сначала определить, какие версии внешних библиотек нужно использовать). Но железяка типа "роутер", не говоря уже о "кардиомонитор", например - это явно не тот случай.