Здравствуйте, 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-систем подчеркивается идея совместимости софта. Врут?