Здравствуйте, B0FEE664, Вы писали:

ЕМ>>Если параметрами библиотеки являются известные, фиксированные свойства целевой системы — они должны быть документированы

BFE>Очевидно, параметры могут быть неизвестны, но, возможно, документированы.

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

BFE>Откуда кросс-средствам знать параметры целевой платформы?

В адекватных кросс-средствах все без исключения параметры сборки задаются в явном виде — в командной строке, в заголовках, в make-скриптах, в конфигах и т.п. Никаких неявных параметров, которые сборочные средства добывают из хостовой системы, трактуя ее, как целевую, там не бывает в принципе. Если бывает — значит, это не кросс-средства, а обычные средства сборки "по месту", которые лишь в силу удачного совпадения можно использовать для кросс-сборки.

BFE>Вы не забывайте, что сами кросс-средства тоже иногда собираются из исходников.

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

BFE>Задача: сделать средство кросскомпиляции, которое будет работать для любых целевых архитектур, даже ещё не созданных. Как такую задачу решить?

Она решена давным-давно: такое средство требует себе на вход всех параметров целевого окружения, которые могут иметь значение для результата компиляции. Если параметров достаточно, компиляция и сборка проходят успешно. Если каких-то параметров не хватает или они создают противоречие — компиляция аварийно завершается.
Принципиально кросс-компиляция ничем не отличается от локальной компиляции — результат полностью определяется набором средств и их настройкой.

BFE>/asdf/asd/qwe/asd_asdfghjklas/asdfghjklh/adadadada.aaaa.aaaaaaaaaaa/qwertyuouy/sdf/asd_werty/asd/ljutdbms/aassdfgta/xdrtyhbvfgd/ddd.sdfrdgrdg.dd/dft.sgsgsgsgsg/sss_sdfrtgddfvxcdAndhjdjdkdkdkdlAtffhjkklsbddyecetdDuringhdjdlddydbLimitdsSgfhkfifnSkfdkfjjwqwaInvariant.cpp

Мне одному кажется, что здесь видна явная тенденция к удлинению имен сверх разумной, или еще кто-нибудь так считает?

BFE>Считали извращением кросскомпилировать исходники линаксав не из под линаксов.

Как я понимаю, до сих пор считается извращением кросс-компилировать любые линуксовые исходники вне системы, где будет работать софт (упомянутый true linux way"). А многие ли понимают, что это тупиковый путь? Чем это принципиально отличается от использования литералов вместо именованных констант, глобальных переменных вместо параметров функций и т.п?

ЕМ>>Тогда, наверное, стоило бы при обсуждении проблем с кросс-компиляцией оговаривать, что бОльшая их часть возникает от кривизны рук на разных уровнях.

BFE>Почему именно рук?

Потому, что выражение такое. Если что-то получается плохо, принято говорить о кривых руках, даже если в основе лежит кривая идея.

BFE>Вам дают продукт как есть: не хотите — не пользуйте.

А какие соображения поддерживают оставление продукта в таком состоянии?

ЕМ>>пусть хоть к char'у приводят, но пишут в документации: "библиотека не поддерживает архитектуры, размер указателей в которых превышает sizeof (char)".

BFE>Вполне возможно, что где-то в недрах исходников, в комментарии так и написано. И что?

Я б такую библиотеку использовал лишь в крайних случаях, когда без нее совсем никак. Насколько часто такое бывает? Я еще могу понять, когда такое используется "чиста у себя" — "как-то получилось, и хрен с ним". Но получается, что такие библиотеки регулярно включаются в массовые продукты, и это считается вполне нормальным.

BFE>portability без compatibility — это легко.

Compatibility — это ж не только о двоичной совместимости. Это совместимость и по идеологии, набору функций, файловым системам, ключевым утилитам, их параметрам и функциональности и прочему. Если в линуксе на какой-то платформе не будет bash'а или совместимой с ним оболочки, а все скрипты будут переписаны на другой язык — это будет еще линукс, или уже что-то другое?

Ну и сама идея portability автоматически подразумевает, что хотя бы первая сборка ядра и основного софта под новую платформу будет проходить в другой системе. Тут бы и сообразить, что описание целевой системы в явном виде должно быть правилом, а не исключением для таких случаев.