@Iron Bug @nprofile1q...
https://en.cppreference.com/cpp/string/basic_string
std::string магическим typedef'ом превращается в basic_string, к которому через using подставляюются шаблонные аргументы, так эти аргументы там разные и зависят от версии стандарта. Что за сверхразум это придумал - не знаю.

@Iron Bug @nprofile1q... даже не отсюда. ABI продуман так, чтобы правильно написанный код не ломался пока не использует новые фичи. Но в разных стандартах std::string это разные классы, из-за чего линковка и ломается. То есть проблема совершенно не на бинарном уровне, а на логическом. Однако, разные ABI всё равно будут несовместимы между собой, как минимум из-за разного манглинга, а где-то и calling conversion, потому в интерфейсах от плюсов часто отказываются. Даже COM-подобные интерфейсы могут поломаться из-за calling conversion (на x86 где-то cdecl, а где-то thiscall)

@Iron Bug @nprofile1q... я для своих проектов решил просто исключить использование STL. Почти всё, что там есть можно реализовать без него, а что нельзя (вроде initializer list) - обычно сомнительные и непортабельные фичи. Но даже если использовать STL - то он ни в коем случае не должен появляться в каких-то интерфейсах и API, потому что сам стандарт делается без учёта переносимости и реализация даже какими-то костылями не может это вправить. Самое банальное - собираем 2 объектника с разными версиями стандартов и у интерфейсных методов вылазят разные сигнатуры - они больше не линкуются. И сколько раз уже это происходило после обновления gcc, что кто-то передал в аргументах std::string и он поменял сигнатуру.

@Iron Bug @nprofile1q... >и последнюю пятую, и шестую
Они собираются, именно последние
Но когда мне надо было отбисектить регрессию, повяившуюся не в последней пятой, я обнаружил что там уже ничего не собирается, причём в каждой версии по разному. А последняя пока что собирается т.к её допатчивают, чтобы собиралась и работала.

@Iron Bug @nprofile1q... я не понимаю, почему они его называют qtquick, когда оно катастрофически медленное.

@Iron Bug @nprofile1q... всё равно qml и декларативщине не место ни в embedded, ни тем более в мобилках. В qtquick как раз скриптинг на js встроен, так что qt в том виде, в каком он там применяется - та ещё субстанция. Насчёт возможности собрать действительно пригодный для embedded'a qt утверждать наверняка не буду, но я сильно сомневаюсь.В qt5 отключение того или иного компонента приводило к ошибкам сборки в других, совсем с ним не связанных. И это только то, что можно отключить вручную опциями, на релизных тегах. Код отвратителен и не оттестирован. Я подозреваю,ч то последним нормальным qt был 4, либо ранние 5 (до 5.7 точно) - дальше можно судить хотя бы потому, что версии начиная с 5.7 в современной системе уже не собираются - ломается парсер версии компилятора, рассыпается STL лапша (зачем им вообще stl?? у них своя шаблонная библиотека есть). 5.15 пока что работает, пока его патчат под современную систему, потом тоже всё сломается намертво. В общем, в qt полный бардак, который чинить уже никто не будет

@Iron Bug @nprofile1q... Тут всё познаётся в сравнении. Были j2me и javacard, которые с аппаратным ускорением (вроде jazelle/thumbee) были хоть и не очень быстрые, но не тормозные. Андройд тормозит не из-за жабы уж точно, скорее из-за котлина и bloat-oriented программирования. Был ещё firefox os, который вместо жабы тащил ещё более тяжёлый уеб и фуксия с флаттером, на фоне которой жаба просто отдыхает. всегда можно сделать хуже. К слову говоря, андройд с его жабой работает быстрее, чем sailfishos с qt5 и pmos/phosh с гномом. Так же не забываем что сейчас и в линуксах повсюду пихают js, react native, electron/tauri, экосистемое говно (pip/npm/cargo), достигая не меньшей раздутости, а проблемы несовместимости libc пытаются решить через контейнеры весто нативных сборок

@Iron Bug @nprofile1q... так то оно да, но видимо всё слишком быстро работало и потому решили всё обмазать selinux'ом

@Iron Bug @nprofile1q... selinux там не для безопасности юзера, а для безопасности данных внутри приложений (чтобы юзер или другое приложение не могло туда смотреть). Безопасность непосредственно юзера никого не волнует

@Iron Bug @nprofile1q... не совсем так, там всё очень сильно ограничено через selinux (белый список вообще всего, что можно делать) и тот же netlink к примеру не работает. Получение списка адаптеров реализовано как-то в обход, вот тут возможна проблема, что андройдовая реализация отдаёт девайсы и адреса, которые софт не должен был видеть

@Iron Bug @nprofile1q... дешевле или проще условия?

@nprofile1q... @Iron Bug ох уж эти tun2socks костыли...
А не может ли случайно шпиёнское приложение запустить свой socks proxy на том же порту с SO_REUSEADDR и перенаправить трафик на себя?