Здравствуйте, Евгений Музыченко, Вы писали:

BFE>>Очевидно, параметры могут быть неизвестны, но, возможно, документированы.
ЕМ>Мне, наоборот, очевидно, что сама идея библиотеки с неизвестными параметрами,
Параметры известны, вручную их редактировать долго, но можно.

BFE>>Вы не забывайте, что сами кросс-средства тоже иногда собираются из исходников.
ЕМ>Если они собираются исключительно для использования там же, где собирались — значит, их сборка не имеет никакого отношения к "кросс"-технологиям.
Имеет. Для кросс компиляции нужен компилятор, который умеет в эту кросскомпиляцию. А где его взять? Правильно — собрать из исходников.

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

ЕМ>Принципиально кросс-компиляция ничем не отличается от локальной компиляции — результат полностью определяется набором средств и их настройкой.
Ага. Теоретически теория совпадает с практикой.

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

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

BFE>>Вам дают продукт как есть: не хотите — не пользуйте.
ЕМ>А какие соображения поддерживают оставление продукта в таком состоянии?
Иногда, для заработка денег, иногда из за нехватки времени. А в целом я не знаю.

ЕМ>Я б такую библиотеку использовал лишь в крайних случаях, когда без нее совсем никак. Насколько часто такое бывает?
Зависит от политики компании. Если политика: "ничего своего не пишем, если уже можно взять написанное", то тащат всё подряд не взирая на качество кода.
Если политика: проверяем всё, так как от нашего кода зависит безопасность, то даже из C-шного стандартного printf могут выкинут функциональность вывода чисел с плавающей точкой, так как такая конвертация не однозначна и занимает много места.

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

BFE>>portability без compatibility — это легко.
ЕМ>Compatibility — это ж не только о двоичной совместимости. Это совместимость и по идеологии, набору функций, файловым системам, ключевым утилитам, их параметрам и функциональности и прочему. Если в линуксе на какой-то платформе не будет bash'а или совместимой с ним оболочки, а все скрипты будут переписаны на другой язык — это будет еще линукс, или уже что-то другое?
Конечно линукс. У bash'а есть несколько альтернатив, штук 5 или больше.
А у Windows, например, есть несколько альтернативных графических интерфейсов. И что? Это уже не Windows?

ЕМ>Ну и сама идея portability автоматически подразумевает, что хотя бы первая сборка ядра и основного софта под новую платформу будет проходить в другой системе.
Ну почему же? Человека, который ратует за то, чтобы править все параметры вручную, не затруднит прямо в кодах набивать программки. Взгляните, например, на мой никнейм. ....

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Как я уже объяснил, это проблема не кросс-компиляции, а линуксового подхода к ней.
Это реальность, а не линуксовый подход

ЕМ>Это уже вообще никак не связано с местом сборки.
Это связано с тем, что для тестирования нужна целевая машина, или виртуальная или реальная. Раз инфраструктура для машины нужна по любому, сборка на целевой машине может быть значительно проще кросс-компиляции.

ЕМ>Я свой виндовый софт тестирую в нескольких виртуалках с разными версиями винды, и на одном ноутбуке c Win 7/10, но даже в страшном сне не приходила в голову мысль взгромоздить туда средства разработки.
Юнит-тестов во время сборки у тебя нет?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Особенно любопытно, как это объяснять тем, кто делает софт для микроконтроллеров Intel/PIC/AVR, для которых "нативных" компиляторов не существует в природе.
Так это многое объясняет: а) у тебя нет альтернативы б) нет сложных зависимостей (а-ля Qt c аппаратной поддержкой OpenGL).
С малиной дело обстоит иначе: во многих случаях настроить малину куда быстрее, чем настраивать кросс-компиляцию.

ЕМ>Если на практике непрозрачно, причина может быть только одна — кривая кросс-система. Других причин не бывает.
Собери на винде приложение с поддержкой OpenGL для RPi4. Уверен, что потратишь время раз в дцать больше, чем установка ОС, gcc, git, cmake, ninja и Qt на малину с нуля.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Я говорю прежде всего о том, что само по себе разделение на "свою" и "чужую" ОС является сугубо искусственным и не обосновано ничем, кроме упрямого желания "просто хочу, чтоб было так". Система разработки/сборки вообще не должна содержать таких категорий. Она должна тупо получать на входе исходники, библиотеки и параметры сборки в явном виде
Это усложняют куда более типичную задачу для Линуксового мира: распространение софта в исходниках. Классическое "configure && make && make install" как тогда будет работать?

Здравствуйте, Евгений Музыченко, Вы писали:

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

Здравствуйте, Евгений Музыченко, Вы писали:

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

З.Ы. Под малину мы используем и нативную и кросс-компиляцию.

ЕМ>Я говорю прежде всего о том, что само по себе разделение на "свою" и "чужую" ОС является сугубо искусственным и не обосновано ничем, кроме упрямого желания "просто хочу, чтоб было так". Система разработки/сборки вообще не должна содержать таких категорий. Она должна тупо получать на входе исходники, библиотеки и параметры сборки в явном виде, тогда на выходе всегда будет предсказуемый результат, никак не зависящий от ее текущего окружения. Для удобства в ней может быть режим "взять параметры из родной системы", но это должен быть лишь один из возможных равноправных вариантов, а не стандартный и предпочтительный.

Да, желание-то хорошее, но в силу исторических причин не срослось-с. Правильные подвижки в этом направлении демонстрирует zigcc, умеющий при работе в режиме C–компилятора без лишних танцев с бубнами генерировать бинарники под все доступные для clang целевые платформы. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html

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

ЕМ>>Мне одному кажется, что здесь видна явная тенденция к удлинению имен сверх разумной, или еще кто-нибудь так считает?
BFE>Видна, не видна, важно, что gcc такое не тянет.
Звучит как баг, не?

BFE>А у Windows, например, есть несколько альтернативных графических интерфейсов.
И как мне в 10й винде включить интерфейс от 7й?
Или ты всё таки про графические API?

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

ЕМ>>>Мне одному кажется, что здесь видна явная тенденция к удлинению имен сверх разумной, или еще кто-нибудь так считает?
BFE>>Видна, не видна, важно, что gcc такое не тянет.
CC>Звучит как баг, не?
Как баг, который никто не будет править.

BFE>>А у Windows, например, есть несколько альтернативных графических интерфейсов.
CC>И как мне в 10й винде включить интерфейс от 7й?
Например: http://www.classicshell.net/ ведущий на https://github.com/Open-Shell/Open-Shell-Menu
Я на десятке не пробовал, так как десятка у меня только от конторы, а добиться от конторы права на установку стороннего ПО — сложная процедура.
На семёрке — работает.

CC>Или ты всё таки про графические API?
Говорят, что на десятке API поменяли и поддержка сторонних оболочек стала сложнее, но как на самом деле — не знаю.

ЕМ>Поскольку для линуксов давно наработаны типовые комплекты скриптов, в основу которых положена странная идея "своей" системы, неудивительно, что это создает столько проблем при малейшем отступлении от привычных вариантов.

По сути-то необходимо соблюсти всего лишь два нюанса:

1. gcc/clang тащит с собой кодогенерацию под все известные триплеты "аритектура-ос-libc";
2. gcc/clang не имеет никаких умолчаний: всё надо передавать явно. Каждый define, каждый путь к директориям с заголовочными файлами и библиотеками, каждый флаг компиляции.

Однако, подобный тулчейн будет ломать все исторически сложившиеся практики, и по-моему именно поэтому никогда не станет стандартным.

PS. Припоминается один грязный трюк для сборки исполняемого бинарника с покрытием как можно большего количества linux'ов: статическая линковка с musl libc. Бинарь сразу перестаёт зависеть от версии glibc, чем печально славится большинство дистрибутивов: соберешь под одну версию, а под другой отваливается. Однако, под некоторыми дистрами, нарушающими кое-какие древние неписанные конвенции размещения системных файлов в фиксированных локациях на ФС (например, /etc/hosts всегда лежит по пути /etc/hosts), этот трюк тоже хрен поможет

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

ZZ>PS. Припоминается один грязный трюк для сборки исполняемого бинарника с покрытием как можно большего количества linux'ов: статическая линковка с musl libc. Бинарь сразу перестаёт зависеть от версии glibc, чем печально славится большинство дистрибутивов: соберешь под одну версию, а под другой отваливается.

Собираешь под самую старую и всё, разве нет?

ZZ>Однако, под некоторыми дистрами, нарушающими кое-какие древние неписанные конвенции размещения системных файлов в фиксированных локациях на ФС (например, /etc/hosts всегда лежит по пути /etc/hosts), этот трюк тоже хрен поможет

Есть дистрибутивы без /etc/hosts?

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

CC>>Звучит как баг, не?
BFE>Как баг, который никто не будет править.
Пусть страдают тогда

CC>>И как мне в 10й винде включить интерфейс от 7й?
BFE>Например: http://www.classicshell.net/ ведущий на https://github.com/Open-Shell/Open-Shell-Menu
Не, это всего то меню и окошко эксплорера. Сам им пользуюсь. Весь остальной интерфейс всё равно от 10ки со всеми его недостатками.

BFE>На семёрке — работает.
На сеиёрке и так интерфейс от семёрки.

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


ZZ>1. gcc/clang тащит с собой кодогенерацию под все известные триплеты "аритектура-ос-libc";

Так clang примерно так и делает.

Например если взять Android NDK.
Там куча x86_64-linux-android28-clang, i686-linux-android29-clang,
armv7a-linux-androideabi31-clang++, aarch64-linux-android29-clang++.

То есть как бы компиляторы для разных двоек: архитектура процессора + ABI Android.
Но на самом деле все эти бинарники это скрипты для вызова "clang/clang++" с нужными аргументами.
То есть для x86_64,i686,armv7a,aarch64 и так далее собирает один clang, в коготорого все это зашито.

llvm на котором основан clang сразу из коробки может собрать под любую поддерживаемую архитектуру,
проблема только в наличие для целевой архитектуры ассебмелера, линковщика (эту проблемы llvm тоже почти решили своим линковщиком(lld))
и runtime.

vsb>Есть дистрибутивы без /etc/hosts?
Clear Linux, например. hosts лежит по пути /usr/share/default/etc/hosts.

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

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

ZZ>По сути-то необходимо соблюсти всего лишь два нюанса:

ZZ>1. gcc/clang тащит с собой кодогенерацию под все известные триплеты "аритектура-ос-libc";

Clang (а точнее llvm) так и работает вообще то. Ну а в gcc в принципе тоже можно организовать что-то подобное — там единственное отличие в том что традиционно плодят отдельные бинарники (да ещё и распространяемые отдельно) со своим именем под каждый триплет. Но можно накачать все нужные в одну папку и сделать простейший скриптик в несколько строк, который будет выбирать нужный по параметру.

ZZ>2. gcc/clang не имеет никаких умолчаний: всё надо передавать явно. Каждый define, каждый путь к директориям с заголовочными файлами и библиотеками, каждый флаг компиляции.

Да вообще то так по сути и работает. Если передашь путь через -I или -L, то в начале все файлы будут искаться именно там. И любой макрос можно предопределить через -D.

Так что в принципе к компиляторам на самом деле нет особых вопросов, они готовы к любым раскладам. Не готовы авторы библиотек и главное авторы скриптов сборки...

ZZ>Однако, подобный тулчейн будет ломать все исторически сложившиеся практики, и по-моему именно поэтому никогда не станет стандартным.

Именно, боюсь эта проблема для C/C++ никогда не будет решена из-за инерции. Но меня это совсем не беспокоит, т.к. на замену C++ уже пришёл Rust (который кстати с помощью LLVM компилирует). А в нём правильные практики организации сборки были заложены изначально, так что сейчас уже стали нормой для сообщества.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Да и ради бога. Только проверять все это они должны не "где-то здесь", а по вполне конкретному конфигу единого формата, на который можно явно указать. Этот конфиг должен создаваться при сборке каждой системы, более-менее документирован, чтоб его можно было хоть скопировать с целевой системы, хоть создать заново по ее описанию. И тогда сборка "где угодно подо что угодно" автоматически работала бы правильно.

https://github.com/freebsd/freebsd-src/tree/main/contrib/sendmail/cf/ostype

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

_>>Есть ядро Linux и сотня разных дистрибутивов на его базе, с десятками несовместимых версий

ЕМ>Так я в курсе. Но, раз уж образовался такой зоопарк — в чем проблема фиксировать параметры каждого из получающихся вариантов хоть в едином конфиге, хоть в наборе из нескольких, но известных конфигов? Насколько я знаю, это всегда использовалось во всех ОС, которые генерировались "по месту", с привязкой к конкретному железу и конфигурации. И только в линуксах сборочные скрипты выясняют, какие библиотеки и утилиты есть в системе, сканируя каталоги.

1) Ничто не мешает вызывать условный ./configure с пачкой --with-xxx/--without-xxx/etc. (что постоянно и делают авторы, но не исходных софтин, а инструкций пакетирования в дистрибутиве)

2) Ты представляешь себе коммуникацию между авторами, условно, 10 основных дистрибутивов и 20000+ включённых в них программ, часть которых (авторов) просто не в курсе, что на основе их продукта есть пакет в каком-нибудь PolarZooLinux?

Я — нет.

А там, где требуются существенные допилы, часто и пишут в апстрим "вы тут что-то слишком сложное написали, оно так работать не будет".

Autotools с автодетектом не зря придумали, они как раз по сравнению с описанным подходом, как в sendmail и прочих ровесниках, дали огромный шаг вперёд по облегчению суммарного труда.

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

Проблема в том, что той специфики от общего кода слишком мало, чтобы из-за неё заморачиваться такой прослойкой...

Здравствуйте, Евгений Музыченко, Вы писали:

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

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

Вменяемые пользователи таких систем (неважно, autotools, CMake, что угодно) так и делают. Любой параметр можно задать через подобный входной конфиг, а если нет — тогда оно начинает искать само.

Если речь про вариант глобального выключения автопоиска — я где-то такое видел (возможно, и в CMake, но не в autotools). Да, это полезно для проверки самой обстановки...
Хотя, я читал, если в autotools задать кросс-компиляцию ключами даже в ту же среду, что хостовая — так и будет. (Если не сломали. Мне влом проверять.)

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

Не извращением напрямую. А лишней работой там, где можно сделать проще.
Но если видят в этом реальный смысл — делают.
Пример с малинкой как раз из этой серии.
Или у меня сейчас проект с целевой ARM (обеих разрядностей) и хостовой x86. Успешно собирается и работает. Проблемы, конечно, есть, но не от того, что кросс-компиляция, а от других вещей (например, ради комбинирования слоёв логики апстрима и местных доточек в Yocto такое навернули, что местами вешаться хочется).

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

Сейчас до чёрта линуксов без bash или где /bin/sh не bash. Как раз с таким вожусь.
Тут ещё веселее — мы это, конечно, прямой задачей не ставили, но двое коллег уже обломались с тем, что Yocto не ставит полный less, а вместо его втыкает busyboxʼовский. Вот тут сложнее, чем все проблемы с кросс-компиляцией: выпутаться из его конструкции layerʼов.

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

Для средств сборки и минимального обеспечения вокруг них. А дальше — как легче.