Здравствуйте, alpha21264, Вы писали:
A>Она там не "работает". Она там "есть". Без программ.
В том же состоянии, что и линукс после появления новых платформ. Все, что есть в исходниках под винду для x86/x64, с легкостью собирается под ARM (хоть 32, хоть 64), если оно не заточено под особенности архитектуры. Но то же самое касается и линукса. Если же в исходниках чего нет, оно и под виндой, и под линуксом появится не раньше, чем соберет разработчик.
A>Вот ровно потому что.
Ровно настолько, насколько платформа востребована. Навскидку, под ARM64 уже давно подтянули FAR, 7-Zip, утилиты SysInternals, еще что-то по мелочи. Пишут, что MS уже выкатили студию под ARM64 — с прицелом на то, чтоб разработчики ставили винду на Mac M1/M2.
ЕМ>При том, что в винде принципиально нет понятия "сборка под родную систему". В ней всегда была и есть "просто сборка". Что под свою систему, что под чужую, что под линукс, что под МК — результат определяется исключительно набором и настройкой используемых средств.
Это всё красивые концептуальные речи. А теперь пара вопросов из грязной приземлённой практики:
1. Компилятор msvc с хост-архитектурой x86_64-windows сумеет выдать статическую или динамическую библиотеку с target–архитектурой arm–linux, которую потом успешно всосёт gcc или clang под целевой ОС?
2. Какая-нибудь роутерная прошивка OpenWRT потребует под виндой менее забористых и более прямых build–скриптов по сравнению со сборкой оной под линуксом?
По-моему Вы просто основываете свои утверждения на маргинальных примерах сборки под MK, то есть под bare metal target. В этом случае все телодвижения действительно на порядок проще оных при сборке именно под чужую ОС.
Здравствуйте, /aka/, Вы писали:
A>>>Вау. Расскажи, какие публичные проекты ты собирал на виндовсе под линукс? _>>...у нас был нативный клиент на C++, который собирался из одних исходников в десяток разных дистрибутивов, под множество ОС A>Выделено же — публичные проекты. Зачем лезть со своими белыми и пушистыми исходниками? У нас тоже есть наш код, который из одних исходников кросс-компилируется под разные платформы. A>Сборка своего не даёт тебе никакого понимания о тех конюшнях, которые придётся разгребать, когда будешь собирать чужое, не подготовленное авторами к кросс-коспиляции.
Так наш проект то использовал десятки открытых библиотек, которые в начале надо собрать, опять же под все целевые платформы. И там встречалось всякое. Были и по сути не зависящие от платформы, такие как Boost (во всяком случае большая часть их библиотек). Были и нормально собирающиеся под все платформы, но ценой очень сложного кастомного скрипта сборки (такие как Qt, OpenSSL и т.п.). А были и вообще без подготовки под все платформы, так что приходилось для них самим писать универсальные (под все платформы) скрипты сборки, как например для библиотеки UDT. Так что опыта игр в эти дела более чем достаточно и происходило это всё с Windows (правда с Линуха или Мака оно всё было бы точно так же).
Здравствуйте, zx zpectrum, Вы писали:
ЕМ>>При том, что в винде принципиально нет понятия "сборка под родную систему". В ней всегда была и есть "просто сборка". Что под свою систему, что под чужую, что под линукс, что под МК — результат определяется исключительно набором и настройкой используемых средств. ZZ>Это всё красивые концептуальные речи. А теперь пара вопросов из грязной приземлённой практики: ZZ>1. Компилятор msvc с хост-архитектурой x86_64-windows сумеет выдать статическую или динамическую библиотеку с target–архитектурой arm–linux, которую потом успешно всосёт gcc или clang под целевой ОС?
MSVC — это убогое недоразумение. Я его держал у себя исключительно для целей сравнения. А так, все сборки для видны были или с помощью gcc (mingw) или clang'a, которые просто на голову лучше (правда каждый по своему). Ну и есть конечно ещё icc, но это отдельная тема для тех, кому критичен каждый такт и платформа только Intel Х86.
ZZ>2. Какая-нибудь роутерная прошивка OpenWRT потребует под виндой менее забористых и более прямых build–скриптов по сравнению со сборкой оной под линуксом?
OpenWRT — это как раз классический Linux дистрибутив и как все они является самой проблемной целевой платформой для кросс-компиляции. Я подробном писал об этом выше.
ZZ>По-моему Вы просто основываете свои утверждения на маргинальных примерах сборки под MK, то есть под bare metal target. В этом случае все телодвижения действительно на порядок проще оных при сборке именно под чужую ОС.
А скажем сборка под Android (если что, это в данный момент самая массовая ОС на планете) надеюсь не является маргинальным примером? И там кстати тоже ядро Linux... Но при этом кросс-компиляция изначально идеально продумана и работает одинаково беспроблемно на любой хост-системе.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>1. Компилятор msvc с хост-архитектурой x86_64-windows сумеет выдать статическую или динамическую библиотеку с target–архитектурой arm–linux, которую потом успешно всосёт gcc или clang под целевой ОС?
Не уверен, поскольку задачи полной совместимости по библиотекам там никогда не стояло — только по исходникам. Если нужно собирать непременно библиотеки в линуксовых форматах, может оказаться проще использовать на хосте те же gcc/clang. Только какой может быть смысл в таком сочетании, кроме того, что библиотеки нужных форматов недоступны, и их исходники тоже?
ZZ>2. Какая-нибудь роутерная прошивка OpenWRT потребует под виндой менее забористых и более прямых build–скриптов по сравнению со сборкой оной под линуксом?
Вряд ли, поскольку роутерные прошивки изначально собирались только в кросс-режиме, а после того, как появились роутеры, способные собирать их локально, вряд ли кто-то заморочился с переделкой под такой режим.
ZZ>все телодвижения действительно на порядок проще оных при сборке именно под чужую ОС.
Я говорю прежде всего о том, что само по себе разделение на "свою" и "чужую" ОС является сугубо искусственным и не обосновано ничем, кроме упрямого желания "просто хочу, чтоб было так". Система разработки/сборки вообще не должна содержать таких категорий. Она должна тупо получать на входе исходники, библиотеки и параметры сборки в явном виде, тогда на выходе всегда будет предсказуемый результат, никак не зависящий от ее текущего окружения. Для удобства в ней может быть режим "взять параметры из родной системы", но это должен быть лишь один из возможных равноправных вариантов, а не стандартный и предпочтительный.
Здравствуйте, alex_public, Вы писали:
_>тоже ядро Linux... Но при этом кросс-компиляция изначально идеально продумана и работает одинаково беспроблемно на любой хост-системе.
Самое смешное, что не надо ничего "идеально продумывать". Достаточно убрать (а еще лучше — изначально не вводить) разделение на "свою" и "чужую" системы, как все проблемы совместимости исчезнут, и останутся лишь вопросы удобства — в каком виде задавать параметры, как организовать хранилище и т.п.
По сути, это же самые азы абстракции — вместо конкретного значения использовать "x", "n" и прочее. И в математике, и в программировании они всегда приветствовались. И переменные в makefile тоже были введены, чтобы уйти от конкретных значений. Странно, как при таком подходе могла появиться парадигма "собираем всегда под себя" — тем более, что в 70-е уже хватало машин, идентичных/совместимых по системе команд, но сильно различавшихся по доступным ресурсам и удобству среды. Казалось бы, идея собирать что сам unix, что софт под него, на более мощной/удобной машине, а затем переносить на целевую, должна была возникнуть автоматически.
Я в 80-е много работал на PDP-11 с RSX-11M, ее тоже нужно было "генерировать" под типы целевого процессора, набор устройств, конфигурацию ПО и т.п. Но на любой машине можно было сгенерить систему под любую другую, лишь бы она поддерживалась. Встроенных кросс-средств в той системе не было, но лишь потому, что все было написано на ассемблере, и настройка на аппаратуру обеспечивалась обычной условной трансляцией. Будь оно написано на ЯВУ, точно так же работал бы и компилятор, позволяющий задавать целевую архитектуру.
И привязка к ядру там тоже была — любой драйвер или системную утилиту нужно было транслировать с файлом системных определений, а собирать — с файлом символов от ядра, чтобы состыковать адреса. Но с тем же успехом можно было подсунуть файлы определений и символов от другой системы, а потом скопировать бинарник туда — я так делал регулярно, чтобы не ходить из зала в зал. Это было нетрудно, поскольку единой системы сборки не было, все задавалось в командной строке или в индивидуальном командном файле.
Поскольку для линуксов давно наработаны типовые комплекты скриптов, в основу которых положена странная идея "своей" системы, неудивительно, что это создает столько проблем при малейшем отступлении от привычных вариантов.
Здравствуйте, /aka/, Вы писали:
A>Сборка своего не даёт тебе никакого понимания о тех конюшнях, которые придётся разгребать, когда будешь собирать чужое, не подготовленное авторами к кросс-коспиляции.
А так уж надо ли эти конюшни разгребать? Я уже столько раз видел как оказывалось дешевле и быстрее "взорвать руины и построить сразу нормально" что у меня уже аллергия на опенсорсные копролиты.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Мне вот интересно, есть ли хоть одна надобность, не говоря уже о "еще какой". Единственное, что приходит на ум — отсутствие нормального кросс-компилятора для целевой платформы. Но такое, насколько я знаю, кончилось еще лет двадцать назад.
1. Кросс-компиляция с некоторыми зависимостями может быть проблемной, например Qt.
2. Тестирование после сборки.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это какая-то крайне извращенная технология. Если параметрами библиотеки являются известные, фиксированные свойства целевой системы — они должны быть документированы и там, и там, и никаких сложностей с заданием значений возникать не должно.
Очевидно, параметры могут быть неизвестны, но, возможно, документированы.
ЕМ> Если же библиотеке нужна "тонкая настройка" на целевую платформу (какие-то нюансы аппаратной или программной конфигурации, производительности и т.п.), то конфигуратор должен быть сделан так, чтобы собрать его кросс-средствами было предельно просто, в идеале — в одну командную строку.
Откуда кросс-средствам знать параметры целевой платформы? Вы не забывайте, что сами кросс-средства тоже иногда собираются из исходников.
ЕМ>Ну и так заморачиваться со статической конфигурацией имеет смысл лишь в том случае, когда динамическая (при инициализации библиотеки уже на целевой платформе) обходится неоправданно дорого.
Иногда это просто не возможно.
ЕМ>То есть, проблема снова не в кросс-компиляции, как таковой, а в явной кривизне софта, ей подвергаемого.
Задача: сделать средство кросскомпиляции, которое будет работать для любых целевых архитектур, даже ещё не созданных. Как такую задачу решить?
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
И это при том, что были предприняты усилия по сокращению длины имён каталогов: многие из имён каталогов были по 40-50 символов длиной, да и вложенность была поболее.
BFE>>Просто ограничение в винде накладывают естественным образом ограничения на пользователей, а вот начинаешь что-нибудь развесистое из другой системы копировать и облом. ЕМ>Вот и вопрос, отчего оно в той системе такое развесистое. Скажем, насколько часто в программах на C++ встречаются имена, полная запись которых (со всеми namespace-ами, именами классов и прочим) дотянет хотя бы до 200 символов?
Не часто, но встречается.
BFE>>Все исходники открыты, можете заняться. ЕМ>А мне оно на хрена? Я предпочитаю называть каталоги именами разумной длины, чтоб путь, по возможности, не превышал 100-120 символов.
Так я о том и говорю, никто это чинить не будет.
BFE>>Это не будут чинить по другой причине: поставил WSL и нет таких проблем. ЕМ>А по какой причине не чинили пятнадцать лет до появления WSL?
Считали извращением кросскомпилировать исходники линаксав не из под линаксов.
BFE>>попробуйте убедить какого-нибудь линуксоида устанавливать библиотеки не в систему, а домашний каталог. ЕМ>Тогда, наверное, стоило бы при обсуждении проблем с кросс-компиляцией оговаривать, что бОльшая их часть возникает от кривизны рук на разных уровнях.
Почему именно рук?
BFE>>Ну раз должны, тогда надо назначить ответственного. Есть кандидаты? ЕМ>Ну а кто там в Linux-сообществе отвечает за разработку стандартов и рекомендаций? Вот их и назначать. Не-не-не. Вам дают продукт как есть: не хотите — не пользуйте.
ЕМ>Если это делается грамотно и корректно в рамках поддерживаемых архитектур — пусть хоть к char'у приводят, но пишут в документации: "библиотека не поддерживает архитектуры, размер указателей в которых превышает sizeof (char)".
Вполне возможно, что где-то в недрах исходников, в комментарии так и написано. И что?
ЕМ>Почти в любой статье о "Unix Philosophy" упоминается о portability over efficiency. А как добиться portability без compatibility?
portability без compatibility — это легко. Это вообще ортогональные понятия.
A>Да, кстати, есть такая штука — yocto. A>https://www.yoctoproject.org/ A>Я пробовал. Оно даже работает.
buildroot проще для восприятия и тоже работает
Как много веселых ребят, и все делают велосипед...
Здравствуйте, B0FEE664, Вы писали:
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
На винде:
C:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.2006.1.7\amd64_microsoft-windows-fileexplorer.appxmain_31bf3856ad364e35_10.0.19041.1949_none_dde30ee0b2d6f53a\n\squaretile44x44.targetsize-256_altform-unplated_contrast-black_devicefamily-colorfulunplated.png
285 символов, даже подлиннее твоего на глаз
И это в самой винде. Так у меня и 300 символов есть в своих файлах
Здравствуйте, CreatorCray, Вы писали:
CC>На винде: CC>C:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.2006.1.7
Так это ж чисто внутривиндовые дела, они уже больше двадцати лет не создают проблем. Он-то жалуется на то, что gcc использует ANSI-версии файловых фунций, которые не понимают больше 260. И это правильно — каждой такой функции приходится транслировать путь в Unicode, для чего выделять память в стеке. Снятие ограничения в ANSI (в котором нет никакого смысла) привело бы или к увеличению расхода стека, или к необходимости выделять динамически. Если gcc столько времени тянут на ANSI-функциях, ни длинные, ни национальные имена подавляющее большинство не парят.
Здравствуйте, Skorodum, Вы писали:
S>1. Кросс-компиляция с некоторыми зависимостями может быть проблемной, например Qt.
Как я уже объяснил, это проблема не кросс-компиляции, а линуксового подхода к ней.
S>2. Тестирование после сборки.
Это уже вообще никак не связано с местом сборки. Я свой виндовый софт тестирую в нескольких виртуалках с разными версиями винды, и на одном ноутбуке c Win 7/10, но даже в страшном сне не приходила в голову мысль взгромоздить туда средства разработки.
Здравствуйте, 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 автоматически подразумевает, что хотя бы первая сборка ядра и основного софта под новую платформу будет проходить в другой системе. Тут бы и сообразить, что описание целевой системы в явном виде должно быть правилом, а не исключением для таких случаев.
Re[2]: Raspberry Pi and programmable logic device, PLD
Все, что есть в исходниках под винду для x86/x64, с легкостью собирается под ARM (хоть 32, хоть 64), если оно не заточено под особенности архитектуры. Но то же самое касается и линукса. Если же в исходниках чего нет, оно и под виндой, и под линуксом появится не раньше, чем соберет разработчик.
