Здравствуйте, B0FEE664, Вы писали:
BFE>Проблема не только в компиляторах/линкерах, но и в библиотеках.
А там в чем проблема? Если библиотека распространяется только в двоичном виде, то к целевой платформе ее не присобачить никак. Если же в исходниках, то какая разница, где ее компилить/собирать — на целевой платформе, или на рабочей? Здесь я тоже вижу проблему лишь в том случае, когда целевая платформа обкатана, широко используется и имеет развитый набор средств для компиляции/сборки, а та платформа, на которой вдруг приспичило собрать, имеет лишь какой-то урезанный набор. Но тогда возникает вопрос — откуда вообще взялась идея собирать не на целевой?
BFE>В смысле — надуманные? Это реальная проблема
В том посте, на который ссылка, я вижу только искусственно созданные длинные пути. Допускаю, что и в реальных применениях случаются настолько развесистые имена/вложенности, что не влезают в 260 символов, но это явная редкость. В винде ограничение в MAX_PATH кончилось с кончиной 9x/ME, а в NT оно осталось только для ANSI-версий. Чтобы это убрать, достаточно переопределить fopen, findfirst и прочее через соответствующие Unicode-аналоги, добавив трансляцию. Но, исходя из
BFE>и вряд ли её кто-то будет чинить.
подавляющее большинство это не парит, а нарываются лишь любители_чрезмерно_длинных_имен, которых в общей массе крайне мало.
BFE>есть библиотека, а она подключает заголовок, которой нет в системе.
Вот это "заголовки, которые есть в системе" — один из основных источников боли, связанной с линуксами. Обязательное условие наличия в системе компилятора, линкера, заголовков и библиотек сродни требованию о том, чтобы в каждом автомобиле был полный набор инструментов и материалов, позволяющий собрать его с нуля в чистом поле. Это вполне нормально выглядело в древности, но последние лет тридцать это явное извращение. Все эти средства должны быть в виде отдельных, изолированных наборов, и ставиться/подключаться в том составе, что необходим конкретному разработчику.
BFE>Значит этот файл надо копировать из системы, а он тянет другой и так все файлы, один за другим переползают в sysroot...
Вместо этого должны быть явно определенные зависимости — какие именно SDK и библиотеки нужны для сборки. А не бесформенная куча файлов из разных источников в одном месте.
BFE>И если окажется, что компилятор по какой-то причине не понимает вот этот вот заголовок из недр sysroot'a или понимает его не правильно...
Почему такое вдруг может оказаться? Если библиотека заточена под конкретный компилятор или конкретную его версию, то вероятность найти такой компилятор для "большой", ходовой системы должна быть выше, чем для "малой" целевой.
BFE>практика кросс-компиляции возникла из-за нехватки ресурсов для разработки на целевой платформа.
Фраза верна, только слово "ресурсов" здесь нужно понимать не "скорости процессора и объема памяти", а ресурсов вообще — стоимости железа, софта, рабочего места разработчиков, их труда и т.п. Кросс-компиляция возникла где-то в 50-х годах прошлого века, когда сообразили, что при разработке софта для новой машины, в традиционном цикле "ассемблер в кодах, ассемблер на самом себе, компилятор ЯВУ на этом ассемблере" начальные этапы можно пропустить, переделав готовые ассемблер/компилятор для существующей машины под кодогенерацию для новой машины.
А так-то, у любой современной видеокарты ресурсов по уши хватит для сборки того же линукса, только где Вы видели линуксы и компиляторы, работающие непосредственно на видеокартах?
BFE>И несмотря на многолетние наработки безглючных средств отладки так и не было произведено.
Значит, определенный уровень глючности устраивает подавляющее большинство настолько, что дальше бороться с глюками просто лень. Хотя опять не понимаю, в чем может быть проблема сделать сколь угодно безглючные средства удаленной отладки для любого сочетания платформ.
ЕМ>>идея системы, призванной обеспечить совместимость
BFE>Так ведь не было такой идеи.
Почти в любом описании идеологии *nix-систем подчеркивается идея совместимости софта. Врут?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А там в чем проблема? Если библиотека распространяется только в двоичном виде, то к целевой платформе ее не присобачить никак. Если же в исходниках, то какая разница, где ее компилить/собирать — на целевой платформе, или на рабочей? Здесь я тоже вижу проблему лишь в том случае, когда целевая платформа обкатана, широко используется и имеет развитый набор средств для компиляции/сборки, а та платформа, на которой вдруг приспичило собрать, имеет лишь какой-то урезанный набор. Но тогда возникает вопрос — откуда вообще взялась идея собирать не на целевой?
Библиотеки в исходникам. Прежде, чем их собрать, их нужно сконфигурировать. Обычно конфигурация — это такой набор define'ов, который включает/выключает те или иные особенности в коде библиотеки. Или, там, определяет размер int'а в байтах... Часто вместе с библиотекой идёт скрипт, который, например, может скомпилировать тестовый пример, запустить его и по выданному результату добавить тот или иной define в config.h, а этот config.h потом, на этапе компиляции библиотеки, подхватывается и используется. Так вот эту конфигурацию надо проводить на target системе, а для этого там нужно установить компилятор... Ну или потратить несколько дней рассматривая код и подбирая подходящие define'ы.
BFE>>В смысле — надуманные? Это реальная проблема ЕМ>В том посте, на который ссылка, я вижу только искусственно созданные длинные пути.
А вам хотелось бы увидеть реальные строки из моей рабочей системы? Зачем? С какой целью интересуетесь?
ЕМ>Допускаю, что и в реальных применениях случаются настолько развесистые имена/вложенности, что не влезают в 260 символов, но это явная редкость.
Да ну какая там редкость! Просто ограничение в винде накладывают естественным образом ограничения на пользователей, а вот начинаешь что-нибудь развесистое из другой системы копировать и облом.
ЕМ>В винде ограничение в MAX_PATH кончилось с кончиной 9x/ME, а в NT оно осталось только для ANSI-версий. Чтобы это убрать, достаточно переопределить fopen, findfirst и прочее через соответствующие Unicode-аналоги, добавив трансляцию.
Все исходники открыты, можете заняться.
ЕМ>Но, исходя из BFE>>и вряд ли её кто-то будет чинить. ЕМ>подавляющее большинство это не парит, а нарываются лишь любители_чрезмерно_длинных_имен, которых в общей массе крайне мало.
Это не будут чинить по другой причине: поставил WSL и нет таких проблем.
BFE>>есть библиотека, а она подключает заголовок, которой нет в системе. ЕМ>Вот это "заголовки, которые есть в системе" — один из основных источников боли, связанной с линуксами. Обязательное условие наличия в системе компилятора, линкера, заголовков и библиотек сродни требованию о том, чтобы в каждом автомобиле был полный набор инструментов и материалов, позволяющий собрать его с нуля в чистом поле. Это вполне нормально выглядело в древности, но последние лет тридцать это явное извращение. Все эти средства должны быть в виде отдельных, изолированных наборов, и ставиться/подключаться в том составе, что необходим конкретному разработчику.
А я спорю? Но вы попробуйте убедить какого-нибудь линуксоида устанавливать библиотеки не в систему, а домашний каталог. Заранее предупреждаю, что за разрыв шаблона ответственность на себя брать не буду.
BFE>>Значит этот файл надо копировать из системы, а он тянет другой и так все файлы, один за другим переползают в sysroot... ЕМ>Вместо этого должны быть явно определенные зависимости — какие именно SDK и библиотеки нужны для сборки. А не бесформенная куча файлов из разных источников в одном месте.
Ну раз должны, тогда надо назначить ответственного. Есть кандидаты?
BFE>>И если окажется, что компилятор по какой-то причине не понимает вот этот вот заголовок из недр sysroot'a или понимает его не правильно... ЕМ>Почему такое вдруг может оказаться? Если библиотека заточена под конкретный компилятор или конкретную его версию, то вероятность найти такой компилятор для "большой", ходовой системы должна быть выше, чем для "малой" целевой.
Да мало ли любителей переопределять unsigned int в UI32 ? Или приводить указатель на структуру к int'у?
BFE>>Так ведь не было такой идеи. ЕМ>Почти в любом описании идеологии *nix-систем подчеркивается идея совместимости софта. Врут?
Да где вы такое читали? Это в Windows обратная совместимость вплоть до DOSа и ограничение в 256+4 . А в *nix-е у каждого маньяка свой лунапарк с блэкджеком и командой print:
"типичный последователь UNIX'а никогда не может запомнить, как на этой неделе называется команда PRINT" (с) старая классика
Здравствуйте, B0FEE664, Вы писали:
BFE>Часто вместе с библиотекой идёт скрипт, который, например, может скомпилировать тестовый пример, запустить его и по выданному результату добавить тот или иной define в config.h, а этот config.h потом, на этапе компиляции библиотеки, подхватывается и используется. Так вот эту конфигурацию надо проводить на target системе, а для этого там нужно установить компилятор... Ну или потратить несколько дней рассматривая код и подбирая подходящие define'ы.
Это какая-то крайне извращенная технология. Если параметрами библиотеки являются известные, фиксированные свойства целевой системы — они должны быть документированы и там, и там, и никаких сложностей с заданием значений возникать не должно. Если же библиотеке нужна "тонкая настройка" на целевую платформу (какие-то нюансы аппаратной или программной конфигурации, производительности и т.п.), то конфигуратор должен быть сделан так, чтобы собрать его кросс-средствами было предельно просто, в идеале — в одну командную строку. Ну и так заморачиваться со статической конфигурацией имеет смысл лишь в том случае, когда динамическая (при инициализации библиотеки уже на целевой платформе) обходится неоправданно дорого.
То есть, проблема снова не в кросс-компиляции, как таковой, а в явной кривизне софта, ей подвергаемого.
BFE>вам хотелось бы увидеть реальные строки из моей рабочей системы?
Да хоть бы пути с измененными именами примерно той же длины, чтобы стало более-менее понятно — реальная там необходимость в длинных путях, или просто причуда.
BFE>Просто ограничение в винде накладывают естественным образом ограничения на пользователей, а вот начинаешь что-нибудь развесистое из другой системы копировать и облом.
Вот и вопрос, отчего оно в той системе такое развесистое. Скажем, насколько часто в программах на C++ встречаются имена, полная запись которых (со всеми namespace-ами, именами классов и прочим) дотянет хотя бы до 200 символов?
BFE>Все исходники открыты, можете заняться.
А мне оно на хрена? Я предпочитаю называть каталоги именами разумной длины, чтоб путь, по возможности, не превышал 100-120 символов.
BFE>Это не будут чинить по другой причине: поставил WSL и нет таких проблем.
А по какой причине не чинили пятнадцать лет до появления WSL?
BFE>попробуйте убедить какого-нибудь линуксоида устанавливать библиотеки не в систему, а домашний каталог.
Тогда, наверное, стоило бы при обсуждении проблем с кросс-компиляцией оговаривать, что бОльшая их часть возникает от кривизны рук на разных уровнях.
BFE>Ну раз должны, тогда надо назначить ответственного. Есть кандидаты?
Ну а кто там в Linux-сообществе отвечает за разработку стандартов и рекомендаций? Вот их и назначать.
BFE>Да мало ли любителей переопределять unsigned int в UI32 ? Или приводить указатель на структуру к int'у?
Если это делается грамотно и корректно в рамках поддерживаемых архитектур — пусть хоть к char'у приводят, но пишут в документации: "библиотека не поддерживает архитектуры, размер указателей в которых превышает sizeof (char)".
ЕМ>>Почти в любом описании идеологии *nix-систем подчеркивается идея совместимости софта. Врут?
BFE>Да где вы такое читали?
Почти в любой статье о "Unix Philosophy" упоминается о portability over efficiency. А как добиться portability без compatibility?
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Объяснить тебе какие проблемы вызывает кросс-компиляция?
ЕМ>А можно мне?
1) Она не работает. Ты конечно можешь её заставить (иногда),
но она будет всё время отваливаться по самым идиотским причинам и в произвольные моменты времени.
2) Она обязательно соберёт не то. Не под ту архитектуру, не под ту версию.
3) Будешь трахаться с библиотеками и их версиями. На Raspberry у тебя всегда будет одно, на PC другое.
Современной программе всегда нужно не менее 100 разных библиотек.
4) Что-то нужно мудрить с инсталлятором. make install как правило не прокатывает.
5) Оно может конфликтовать с твоей основной средой разработки.
В общем — этим можно заниматься, но только если ты можешь на это тратить полный рабочий день и тебе за это платят.
А если тебе за это не платят, проще установить gcc на саму Raspberry.
Здравствуйте, novitk, Вы писали:
A>>Тем, что я не хочу трахаться с кросс-компиляцией. A>>Объяснить тебе какие проблемы вызывает кросс-компиляция?
N>И какие же? Для большинства MC кросс-компиляция единственный вариант, например та же ардуина.
Мы про Raspberry Pi говорим. Это — полноценный компьютер с полноценным линуксом.
Здравствуйте, c-smile, Вы писали:
CS>Насколько я понимаю это надо делать true Linux way — собирать его на target устройстве.
Зачем?
CS>Альтернативно можно попробовать cross-compiling, но насколько я понимаю это работает только для простых случаев. Или я ошибаюсь?
Ошибаешься.
CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Я очень много времени провел в embedded разработке.
В общем, твоя проблема в том, чтобы найти cross-тулчейн с достаточно большим набором библиотек под него, чтобы он покрывал твои нужды. Поищи, не найдешь — возвращайся. Собираться на самой малинке, ну, я бы такой вариант рассматривал, как запасной. Все-таки на хосте у тебя побольше мегагерцев будет, чем на устройстве.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот это "заголовки, которые есть в системе" — один из основных источников боли, связанной с линуксами. Обязательное условие наличия в системе компилятора, линкера, заголовков и библиотек сродни требованию о том, чтобы в каждом автомобиле был полный набор инструментов и материалов, позволяющий собрать его с нуля в чистом поле. Это вполне нормально выглядело в древности, но последние лет тридцать это явное извращение. Все эти средства должны быть в виде отдельных, изолированных наборов, и ставиться/подключаться в том составе, что необходим конкретному разработчику.
Вот +100500. В винде и в макоси давно всё нормально сделано, есть platform SDK, там всё что тебе надо. Можно поставить их несколько и говорить с какой ты хочешь компилять.
А в линухах до сих пор какие то палки копалки на каждый чих.
ЕМ>Вместо этого должны быть явно определенные зависимости — какие именно SDK и библиотеки нужны для сборки. А не бесформенная куча файлов из разных источников в одном месте.
+100500 №2
ЕМ>Почему такое вдруг может оказаться? Если библиотека заточена под конкретный компилятор или конкретную его версию, то вероятность найти такой компилятор для "большой", ходовой системы должна быть выше, чем для "малой" целевой.
+1
ЕМ>Почти в любом описании идеологии *nix-систем подчеркивается идея совместимости софта. Врут?
Врут, причём я бы даже сказал что наглейшим образом пи%дят.
Хуже совместимости я не видел ещё нигде. Винда и мак просто на световые годы по обеспечению совместимости ушли вперёд.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alpha21264, Вы писали:
A> Современной программе всегда нужно не менее 100 разных библиотек.
Почему то сразу вспоминается пресловутый leftpad
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, alpha21264, Вы писали:
A>1) Она не работает. Ты конечно можешь её заставить (иногда), A> но она будет всё время отваливаться по самым идиотским причинам и в произвольные моменты времени.
Возможно, я что-то делаю не так, но у меня она работает всегда и не отваливается. Возможно, я что-то делаю не так — например, делаю ее под виндой.
A>2) Она обязательно соберёт не то. Не под ту архитектуру, не под ту версию.
Ни разу такого не было. Очевидно, виновата винда.
A>3) Будешь трахаться с библиотеками и их версиями.
С ними приходится трахаться почти всегда, когда они используются, независимо от платформ.
A>На Raspberry у тебя всегда будет одно, на PC другое.
Это опять же из-за кривой идеологии *nix ("в каждой системе обязана быть среда для сборки"), от которой польза только для типовых вариантов, а для нетиповых — сплошной вред. В виндовых средствах сборки принципиально нет понятия "родной среды" — все необходимые средства всегда устанавливаются независимо, в той конфигурации, которая необходима. Конечно, бывают проекты с инструкциями вроде "собирать только под VS 2015.3", но и это всего лишь означает набор известных заголовочных/библиотечных файлов, не более того.
Если мне вдруг приспичит поднять на винде под Raspberry среду для сборки, под нею соберутся правильные бинарники с той же функциональностью, что и под виндой на x64 — хоть для arm64, хоть для x64, хоть для x86. Даже представить себе не могу, что там нужно сделать, чтобы оно вдруг не собралось, или собралось неправильно. Различия могут быть лишь в чисто технических мелочах вроде порядка секций, для которых тот порядок не задан явно — если версии компилятора/линкера будут разными. Одинаковые версии соберут полностью идентичные бинарники и там, и там.
A>Современной программе всегда нужно не менее 100 разных библиотек.
Всегда? Не менее? Точно?
A>4) Что-то нужно мудрить с инсталлятором. make install как правило не прокатывает.
Если скрипты для установки написаны под конкретную версию/конфигурацию системы, то это предсказуемо. Если заявлено, что они могут обслуживать множество систем, но не делают этого — они просто кривые. Но только при чем здесь кросс-компиляция, как таковая? Так и говорите — "скрипты, написанные для халявной сборки под целевой системой, ломаются при изменении конфигурации".
A>5) Оно может конфликтовать с твоей основной средой разработки.
Каким образом? Конечно, если в лучших линуксовых традициях сваливать все заголовки/библиотеки в одну "системную" кучу, в которой они видны глобально и находятся по общим путям, то неудивительно. И сама кросс-компиляция здесь снова ни при чем.
Здравствуйте, alpha21264, Вы писали:
N>>Для большинства MC кросс-компиляция единственный вариант, например та же ардуина.
A>Мы про Raspberry Pi говорим. Это — полноценный компьютер с полноценным линуксом.
Тогда получается, что средства кросс-компиляции и проекты для недокомпьютеров сделаны лучше, чем для "полноценных".
Здравствуйте, Pzz, Вы писали:
CS>>true Linux way — собирать его на target устройстве.
Pzz>Зачем?
Дабы соответствовать.
Помнится, когда-то давно знакомая в разговоре упомянула, что у нее подросла собака, ей "пора купировать уши". На мой вопрос, зачем это нужно, ответила "чтобы соответствовала породе". Следующие полчаса я старательно пытался выяснить, зачем она собирается уродовать животину, но та лишь твердила "мне объяснили, что это требуется для соответствия породе". Тогда эта дама сильно упала в моих глазах.
Позже я где-то прочитал, что та порода была выведена искусственно, и с ушами у этих собак часто возникали проблемы, отчего их и старались подрезать заранее. Но дама в это не вникала, и просто собиралась тупо исполнить то, что ей сообщили то ли в ветеринарке, то ли в собачьем клубе.
Здравствуйте, CreatorCray, Вы писали:
CC>В винде и в макоси давно всё нормально сделано, есть platform SDK, там всё что тебе надо. Можно поставить их несколько и говорить с какой ты хочешь компилять.
В винде в последнее время тоже доминирует тенденция к неграмотности. Даже многие разработчики драйверов весьма туманно представляют себе, что происходит про сборке, и мыслят категориями "ставим такую-то студию, к ней ставим такой-то WDK, создаем проект, нажимаем кнопку, и крутая магия создает нам бинарники".
Но даже при таком подходе сохраняется принцип разделимости. Я SDK/WDK уже много лет не ставлю их собственными установщиками, а тупо распаковываю из MSI нужные подкаталоги в отдельные целевые каталоги, и в каждом проекте указываю соответствующие пути. Немного более громоздко, чем стандартный способ, зато нигде нет неявных зависимостей — все на виду.
Вообще, импортировать заголовки/библиотеки тупо по [коротким и невнятным] именам, в расчете на то, что все пути будут свалены в INCLUDE/LIB, допустимо или в сугубо локальных проектах, не предназначенных к распространению, или когда импортируемые файлы имеют давно устоявшиеся, незыблемые имена (stdio.h, libc и т.п.). Но до сих пор ведь встречаются публичные проекты с чем-то вроде #include <util.h>, где util.h — заголовок в одной из нескольких внешних библиотек.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В винде в последнее время тоже доминирует тенденция к неграмотности.
Увы, идиократия была документалкой, да.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Евгений Музыченко, Вы писали:
CC>>В винде и в макоси давно всё нормально сделано, есть platform SDK, там всё что тебе надо. Можно поставить их несколько и говорить с какой ты хочешь компилять.
ЕМ>В винде в последнее время тоже доминирует тенденция к неграмотности. Даже многие разработчики драйверов весьма туманно представляют себе, что происходит про сборке, и мыслят категориями "ставим такую-то студию, к ней ставим такой-то WDK, создаем проект, нажимаем кнопку, и крутая магия создает нам бинарники".
Как тебе удаётся в одной теме говорить правильные вещи, и в той же теме самому садиться в ту же лужу?
Ты мыслишь категориями "ставим кросс-систему, и крутая магия создаёт нам бинарник, а если не создаёт, то она кривая".
Кросс-системы для малины прямые. На Дебиане на любой платформе уже много лет из коробки, безо всякого напильника, можно создавать бинарник "Hello, world" под все четыре малиновых процессора.
Но "Hello, world" для малины не нужно кросс-компилировать. Он и на самой малине скомпилируется за секунду.
Кросс-компилировать для малины может понадобится большие штуки, которые на малине будут собираться часами. Это значит мегабайты исходных кодов самого приложения и десятки посторонних библиотек, которых гарантированно не будет в самой прямой кросс-системе. И все эти десятки чужих библиотек, подобранных автором целевого продукта по функционалу, а не по качеству подготовки к кросс-компиляции, нужно допилить и кросс-компилировать. В этом трах.
Да, этой проблемы нет при разработке под микрокалькуляторыконтроллеры.
ЕМ>Но даже при таком подходе сохраняется принцип разделимости. Я SDK/WDK уже много лет не ставлю их собственными установщиками, а тупо распаковываю из MSI нужные подкаталоги в отдельные целевые каталоги, и в каждом проекте указываю соответствующие пути. Немного более громоздко, чем стандартный способ, зато нигде нет неявных зависимостей — все на виду.
Теперь представь, что таких SDK надо поставить тридцать. Потому что сейчас модно не писать руками то, что можно подтянуть из чужой библиотеки, и плевать на качество оформления библиотеки, у меня же собралось.
ЕМ>Вообще, импортировать заголовки/библиотеки тупо по [коротким и невнятным] именам, в расчете на то, что все пути будут свалены в INCLUDE/LIB, допустимо или в сугубо локальных проектах, не предназначенных к распространению, или когда импортируемые файлы имеют давно устоявшиеся, незыблемые имена (stdio.h, libc и т.п.). Но до сих пор ведь встречаются публичные проекты с чем-то вроде #include <util.h>, где util.h — заголовок в одной из нескольких внешних библиотек.
Видишь, одну из самых простых проблем при сборке публичных проектов ты уже знаешь. Главное не копай глубже, там ещё хуже.
Здравствуйте, /aka/, Вы писали:
A>Ты мыслишь категориями "ставим кросс-систему, и крутая магия создаёт нам бинарник, а если не создаёт, то она кривая".
Нет, я мыслю примерно так: "если моя основная рабочая система, где все удобно настроено, может собрать бинарники для другой целевой системы, под которой я не работаю регулярно, и там нет удобной среды для сборки, то откуда вообще может взяться идея делать это непосредственно на целевой системе?".
A>"Hello, world" для малины не нужно кросс-компилировать. Он и на самой малине скомпилируется за секунду.
Вот в этом-то все и дело. За десятилетия развития программирования сложилась вполне адекватная практика: средства разработки должны находиться и работать в той системе, где ведется эта самая разработка, а на целевые системы, где разработки не ведется, должны поступать уже готовые бинарники. От этого отступают лишь при крайней необходимости. Когда-то давно любой *nix автоматически являлся и системой разработки под себя, поэтому наличие в нем средств разработки было вполне оправдано. Когда же стали делать на базе него системы, где разработки не предполагалось, следовало как можно быстрее избавляться от традиции прилагать к каждому экземпляру системы еще и комплект из компилятора/линкера, заголовков и библиотек, как когда-то отказались от комплектации каждого автомобиля сундуком с инструментами и запчастями. Но традиция оказалась настолько прилипчивой, что идея жить на вечной стройке завоевала массы, и теперь вам от нее никуда не деться. Именно отсюда и растет корень многих ваших проблем.
A>Кросс-компилировать для малины может понадобится большие штуки, которые на малине будут собираться часами. Это значит мегабайты исходных кодов самого приложения и десятки посторонних библиотек, которых гарантированно не будет в самой прямой кросс-системе.
Так их и не должно там быть. Кросс-система — это набор базовых средств (компилятор, линкер и прочие build tools, стандартные заголовки, библиотеки, универсальные скрипты), с помощью которых можно собирать хоть "hello, world", хоть линукс, под любую из необходимых платформ. Все остальное добавляется отдельно, в явном виде, в нужном сочетании.
Соответственно, если разработка приложения ведется на той самой малине, то логично, чтобы все это было там. Если же разработка ведется в другой системе, то все это логично ставить в нее, а на малине, где не ведется разработка, вообще нет оснований держать что-то из этого.
A>И все эти десятки чужих библиотек, подобранных автором целевого продукта по функционалу, а не по качеству подготовки к кросс-компиляции, нужно допилить и кросс-компилировать. В этом трах.
Потому и трах, что разработчики этих библиотек, грубо говоря, привыкли и работать, и есть, и спать на одном месте, раскладывая всё необходимое вокруг себя, на расстоянии вытянутой руки. О том, что существуют рабочие кабинеты, кухни, столовые и спальни, а также ящики и шкафы, они либо не догадываются (если слаще морковки ничего не видали), либо убеждены, что все это лишнее, и настоящему линуксоиду только вредит.
Забавно, что винда и ее средства разработки, где изначально все было свалено в одну кучу, давно вышли из этого состояния, а в линуксе, вырасшем из униха с его строгим и разумным разделением по принадлежности разных средств, так и остался в идеологии 70-80-х.
A>Теперь представь, что таких SDK надо поставить тридцать.
Да хоть сто, если они сделаны минимально грамотно, а потому не конфликтуют ни друг с другом, ни с системой сборки. Главное, что их достаточно поставить в одну систему — основную, рабочую. А с целевой контактировать лишь постольку, поскольку это нужно для тестирования и отладки.
A>Потому что сейчас модно не писать руками то, что можно подтянуть из чужой библиотеки, и плевать на качество оформления библиотеки, у меня же собралось.
А качество оформления непосредственно вытекает из устоявшейся практики. Вот в унихах изначально была логика распределения и файлов по каталогам, и прав по пользователям, поэтому с этим изначально был относительный порядок. В досе/винде ничего этого не было, поэтому было принято "валить все в систему", и в этом говнище тоже "все собиралось". Потом MS нашел в себе силы поломать эту практику, и уже давно все выглядит достаточно пристойно, в кучу валят лишь самые отморозки. А линукс, наоборот, так и тянет эту порочную практику. Если даже сейчас начать изо всех сил ее искоренять, пройдет лет пять-семь, пока оно сдвинется. Так что вам еще долго с этим жить.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>...когда-то отказались от комплектации каждого автомобиля сундуком с инструментами и запчастями. Но традиция оказалась настолько прилипчивой, что идея жить на вечной стройке завоевала массы, и теперь вам от нее никуда не деться. Именно отсюда и растет корень многих ваших проблем.
У нас нет проблем. Мы можем собирать на разных системах. И у нас хватает опыта выбирать, где это делать удобнее.
Это у тебя проблема понять, что мы объясняем. Вероятно, от отсутствия релевантного опыта.
Про микрокалькуляторыконтроллеры понятно, там выбора нет. Ты вынужден собирать на одной системе, а использовать на другой.
Под какие разные платоформы разных производителей, на которых есть свои среды разработки, ты можешь кросс-компилировать на виндовсе?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Помнится, когда-то давно знакомая в разговоре упомянула, что у нее подросла собака, ей "пора купировать уши". На мой вопрос, зачем это нужно, ответила "чтобы соответствовала породе". Следующие полчаса я старательно пытался выяснить, зачем она собирается уродовать животину, но та лишь твердила "мне объяснили, что это требуется для соответствия породе". Тогда эта дама сильно упала в моих глазах.
Ну если она по выставкам собирается таскаться со своей собачкой, то соответствие породе может быть существенным условием.
(хорошо, что у меня дворняжка, соответствующая своей породе по определению, в любом своем состоянии).
ЕМ>Позже я где-то прочитал, что та порода была выведена искусственно, и с ушами у этих собак часто возникали проблемы, отчего их и старались подрезать заранее. Но дама в это не вникала, и просто собиралась тупо исполнить то, что ей сообщили то ли в ветеринарке, то ли в собачьем клубе.
Проблемы могли возникать при использовании породы по назначению. Например, на охоте. Большинство пород выведены вполне в рабочих целях, а не в декоративных, как они сейчас используются.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>>Для большинства MC кросс-компиляция единственный вариант, например та же ардуина.
A>>Мы про Raspberry Pi говорим. Это — полноценный компьютер с полноценным линуксом.
ЕМ>Тогда получается, что средства кросс-компиляции и проекты для недокомпьютеров сделаны лучше, чем для "полноценных".
Не получается. У тебя что-то с логикой.
На полноценном компьютере можно работать полноценно —
без привлечения других ненужных устройств,
на которые нужно тратить деньги, место и главное — мозги.
Обязательное условие наличия в системе компилятора, линкера, заголовков и библиотек сродни требованию о том, чтобы в каждом автомобиле был полный набор инструментов и материалов, позволяющий собрать его с нуля в чистом поле. 
