Не вы, у разработчиков приложений появится такая возможновть, если либа поддержит динамическую линковку. А если динамическия линковка — почти всегда нужен ABI. Вот представьте: обновился в репе компилер — и хоба, прилетает вместе все 40гиг установки, потому что все надо собирать именно с этой версией. Ставите компилер из тестинг репы потому что вам надо? Ваши проблемы. А так, ментейнер возьмет либу, возьмет приложения, скомпилит в пакадж, проверит что все работает. И весь мир в апдейтах прилетать не будет. Вы можете эти приложения локально собрать, подцепив либу из репы, компилер будет другим наверняка, но работать будет и память будет шариться. Это все благодаря ABI и возможности совмещать модули. Все это разношерстная кампания, разные люди, у них разные системы, разные версии и им вот просто очень сильно надо уметь совмещаться внешне без пересборки мира.
К стаитческой линковке это тоже относится — иногда оно тоже надо, пример с Qt я выше приводил (забыл упомянуть что статически собирал). В дистрах статические либы тоже присутствуют. С ними точно так же желательно не ломаться как можно дольше.
Я вам пытаюсь показать кейс, когда ABI нужен, вы пытаетесь показать кейс где не нужен. Как это к rust относится? Я же конкретно про него пишу — не все либы используют и будут использовать совместимость с си, потому проблема ABI останется. Надо или на си ABI перейти для любой внешней комоновки, или свой стабильный сделать, и это реально очень надо.
Просто возьмите кейс где он нужен, а не статическую линковку qt-rs только к совему приложению. Например задейтесь целью зашарить его загрузку между несколькоми независимыми приложениями, контроля над которыми вы не имеете.
Это не редкие кейсы. Механизм совмещения — фича очень серьезная и используется повсемесно. Пирчем разные модули разрабытывают разные люди/команды/кампании. Связать все это очень важно. Например либу делает одини люди, а используют — другие, вы гарантируете что все либы это сделают, как предлагает khim? Получается я беру либу — проблема, еще беру — еще проблема. И что мне делать? А если все реально начнут делать #[repr(C)] и прочее необходимое, и других вариантов не будет — так проблемы тогда нет, тогда это и будет стабильный ABI для раста.
Вот вам еще пример: вот скомпилил я Qt под asan/tasn. Вот они у меня лежат и я их иногда использую. Мне вот очень не понравиться если все минорные обновления компилера начнут его ломать. Или если я не смогу слинковаться с либой из дистриба немного другим компилером, у мнея их вообще 2, clang и gcc, а в репе собиралось одним (причем точно не ими, потмоу что вот они обновились, а все остальное — нет). Понимаете масштаб проблемы?
Так я про это и говорю: если не нужен ABI, не надо модулей, плагинов, шаринга кода/rdata между независимыми приложениями, удобного интерфейса к JIT и прочего — лучше линковать lto, это эффективнее и сделает каждой функции совой оптимальный ABI.
Речь же про кейсы когда он нужен, а для системного языка — это маст хев. Для потенциального заменителя C/C++ — тоже.
Все верно, это не костыль, а совместимость с си. Просто предлагается в либах и там где нужен стабильный ABI — все это использовать всегда. Но не все это в либах делают, и не всем хочется. Потому будут делать по-разному и проблема останется.
Да, я сталкивался с этим. Обновляешь что-то — и какой-то модуль из зависимостей не собирается из-за сишного модуля. Довольно неприятно и бывает трудно исправить.
У питона полно проблем с совместимостью, я постоянно сталкиваюсь, и лучше бы чтобы их небыло. К тому-же притон интерпритируемый язык, но просто перекопилит кэш сам, там куда больше API/библиотек совместимость едет.
Ну тут я согласен. Можно тогда язык использовть через си ABI, раз своего нет. Но конкретно у раста это потребует всякие #[repr(C)] и libc::*, а не все это делают. Язык получается не самостоятельный и это все равно минус. Свой стабильный ABI — это хорошо, или сделать чтобы все нужные конструкции типа #[repr(C)] были автоматом при экспорте в либы\dll\so. Но постойте-ка, это и получился бы совой стабильный ABI.
А иначе — все таки перекладывание этой проблемы с языка на разработчика. Не рассчитана либа на си — придется решать. А если все либы рассчитаны на си (как вы предлагаетте, всем так делать) — ну так вот он, свой стабильный ABI, стандартизируем как его свой и проблема решена. А пока этого нет — будут делать и так и так и проблема останется.
Не совсем, это просто менее стабильный ABI нежели си и один из вариантов решения возникаемой от поломок пробелмы. Но благодаря поддержке его стабильности в определенных пределах — люди впринципе этом могут этим пользоваться, и пользуются. Это впринципе зачем нужен ABI. Если он совсем часто ломается — это так-себе ABI, поддержка усложнится и пользваться станут реже, или станут от чего-то отказываться, это однозначная проблема для кейсов где он нужен. Если же впринципе отказаться от поддержки стабильности ABI — ну так это равноценно тому что его нет, соответственно кейсы где он нужен просто не применимы.
Все так. На винде решают проблему, поставляя redist c приложением и держа несколько копий мажорных версий в системе. На лине — поддерживая какую-то минимальную версию stdc++.
Так же на лине теперь доступен вариант и как в винде — указывая разные версии core в flatpak/snap, будем попадать на разные версии stdc++. В системе их тоже может стать несколько, и все еще будем их шарить между приложениями.
Да я вкурсе что такое msvcp. Речь про то что он ставится в систему и будет шариться между всеми приложениями, как stdc++ под линем. Чем не интерфейс не на си? Вот WINAPI — да, там везде си, в .net — уже нет, на маке тоже в основном нет. Но это все не к тому, что си интерфейс нажеднее все равно никто не спорит. Это как раз наглядно показывает что это нужная фича, и сишные интерфейсы часто из-за этого выбирают.
Что COM не С++ я тоже вкурсе, но это и не си, хоть из си и можно работать, из си вообще с чем угодно можно работать.
Нет, на винде ABI у дельфи для dll`ок вполне совместим. Ну то есть вы согласны что ABI иногда нужен, и что когда он долго не ломается — это хорошо?
Вы просто к тому что у других языков это не получится и надо всегда делать обертки на си? Ну хорошо, это же не противоречит тому, что ломать ABI плохо. Просто язык значит никогда не будет самостоятельным и требовать си для кейсов когда нужен ABI, именно по этой причине. И чем чаще происходит поломка ABI — тем более это верно.
Вот только не все спешат бежать делать си обертки для своих библиотек. А как миниум С++ и ObjC/Swift в реальной жизни вполне используют. Под виндой какой-то из стабильных msvcp, под линем stdc++ от какой-то версии и получают шаринг между приложениями и приемлимое время жизни приложения.
Отказ от поддержки ABI по сути будет перекладывание работы с разработчика языка на разработчиков библиотек\приложений для кейсов когда он нужен и он никогда не сможет стать именно заменой C/C++.
Вы опять про все пересобрать. Вы понимаете, что если вы можете все пересобрать, — оно вам не надо. А если Far собран С++, а плагин на дельфи, и его создатель не имеет контроля над сборкой фара, и всех его версий у всех, — то ABI нужно. Да, оно кода-нибудь сломается, но ABI тут всё равно нужен, так что обратная мантра тоже не работает. И чем дольше оно не ломается — тем лучше. В вашем варианте мы просто не делаем плагины фару, всегда пересобираем из какой-то репы те что у вас есть.
И какой вид ни делай, если плагины ломаются очень редко — молодцы; часто ломаются — ну не молодцы, но может не сами девелоперы, а девелоперы их языка и возможно действительно переключиться на сишную прослойку хорошая идея. В общем это плохо как ни крути, может быть оправданным, но плохо и делать это стоит как можно реже. Кейсов где ABI нужен полно.
Как это не видели? В винде msvcp*, это хоть и redist и его обычно с приложением поставляют (хотя от старых студий уже вроде в комплекте, от 6й точно), но оно будет шариться между всеми использующими эту стабильную версию приложениями, и ему нужен ABI. Так же directx redist включают, COM интерфейс это тоже не C.
Макось? Полно не сишных интерфейсов, и что печально — сишные opengl и openal депрекейтят.
На лине тоже firefox использует stdc++ из системы, причем там при сборке конфигурится, какую минимально поддерживать. Есть куча других либ с не сишными интерфейсами.
Но вы абсолютно правы, что си интерфейс — наиболее ABI стабильный. А с++ и другие ломаются куда чаще. Именно потому его все любят, когда нужна совместимость. Именно потому — часто ломать ABI плохо, неважно stdc++, rust или go. Это вызывает проблемы в определенных случаях и их придется решать одним из способов.
Проблема тут следующая: Я не собираю игру тем же компилером что steam runtime. И когда пакую ее во flatpak, я не собираю core, но ссылку на него указываю. Понятия не имею, что там за компилер использовался, но игра работает.
Ну то-есть ABI нужен везде, где надо что-то с чем-то совместить, компоненты, где твое может быть только часть. Поставить third party, собрать что-то один раз и использовать либу, сделать dll\so и экономить юзеру память, плагины к какому-то софту итд. Когда все это не надо — ну да, тут эффективнее lto и статическая линковка, ктож спорит.
Все так: glibc — мало проблем, libstd++ — больше, Boost — еще больше; libicu — не сталкивался. Но это не значит что им не пользуются.
У steam runtime, например, достаточно стабильное API/ABI, в пределах дистра благодаря этому куча кода шарится, даже у flatpak/snap идут ссылки на свои core для этих целей. Есть куча более стабильных библиотек что таких проблем не вызывают. И это будет еще только больше проблем если весь этот мир пересобирать раз в несколько месяцев.
Что вы предлагаете — по сути вообще отказаться от ABI, ну так пожалуйста, линкуйте с lto — нужен будет компилер именно той версии, вот оно полностью сломанное ABI уже есть. Это же не значит что нет случаев, когда надо компоненты делать совместимыми, и хочется чтобы эта система пожила подольше и требовала меньше поддержки.
К слову про производительность. Все последние изменения в stdc++ abi они из-за фич языка, не из-за производительности. Производительность да, это хорошо, и над этим думать надо. Но это редко надо, бесконечность итераций тут не надо для одной архитектуры для стабилизации.
То-есть пользоваться растом исключительно через другой язык? Где таки постарались и нарушения ABI редки?
И чем умеют пользоваться, и какие проблемы у всех возникают? C++ ABI умеют пользоваться единицы и у всех с ним проблемы возникают?
Ну так а вы предлагаете еще чаще эти проблемы сделать, а пользоваться умеют все — скомпилил и какой-то ABI получил. И его желательно не замечать, только чинить если у кого-то где-то сломается, а не ломать все время. Вот чинить да, может и единицы умеют. Посмотрите как это в firefox решается для stdc++, и это при редких изменениях, а при нестабильном — будет вообще кошмар.
Ломать его, конечно, приемлимо в некоторых случаях, например если ни либы ни dll\so не нужны. Но в остальном — чем реже тем лучше.
Ну это да. И это порождает определенные проблемы, из-за этого даже вводят всякие _GLIBCXX_USE_CXX11_ABI, и оно даже реально пригождается в реальной жизни. И вот представим что на это забьют и это все станет регулярным. Раз в 3 месяца пересобираем весь мир, к примеру (а проблем с пересборкой конечно же ни у кого не возникнет). А проприетарщина вообще, кому она нужна? Давайте исходники, либы не принимаем.
Это и gcc/msvc уже очень давно делает, и не только для статик, но и для всех при lto/pgo. ABI он наружу, чтобы статические либы и dll\so не протухали каждые несколько месяцев.
Не вы, у разработчиков приложений появится такая возможновть, если либа поддержит динамическую линковку. А если динамическия линковка — почти всегда нужен ABI. Вот представьте: обновился в репе компилер — и хоба, прилетает вместе все 40гиг установки, потому что все надо собирать именно с этой версией. Ставите компилер из тестинг репы потому что вам надо? Ваши проблемы. А так, ментейнер возьмет либу, возьмет приложения, скомпилит в пакадж, проверит что все работает. И весь мир в апдейтах прилетать не будет. Вы можете эти приложения локально собрать, подцепив либу из репы, компилер будет другим наверняка, но работать будет и память будет шариться. Это все благодаря ABI и возможности совмещать модули. Все это разношерстная кампания, разные люди, у них разные системы, разные версии и им вот просто очень сильно надо уметь совмещаться внешне без пересборки мира.
К стаитческой линковке это тоже относится — иногда оно тоже надо, пример с Qt я выше приводил (забыл упомянуть что статически собирал). В дистрах статические либы тоже присутствуют. С ними точно так же желательно не ломаться как можно дольше.
Я вам пытаюсь показать кейс, когда ABI нужен, вы пытаетесь показать кейс где не нужен. Как это к rust относится? Я же конкретно про него пишу — не все либы используют и будут использовать совместимость с си, потому проблема ABI останется. Надо или на си ABI перейти для любой внешней комоновки, или свой стабильный сделать, и это реально очень надо.
Просто возьмите кейс где он нужен, а не статическую линковку qt-rs только к совему приложению. Например задейтесь целью зашарить его загрузку между несколькоми независимыми приложениями, контроля над которыми вы не имеете.
Это не редкие кейсы. Механизм совмещения — фича очень серьезная и используется повсемесно. Пирчем разные модули разрабытывают разные люди/команды/кампании. Связать все это очень важно. Например либу делает одини люди, а используют — другие, вы гарантируете что все либы это сделают, как предлагает khim? Получается я беру либу — проблема, еще беру — еще проблема. И что мне делать? А если все реально начнут делать
#[repr(C)]и прочее необходимое, и других вариантов не будет — так проблемы тогда нет, тогда это и будет стабильный ABI для раста.Вот вам еще пример: вот скомпилил я Qt под asan/tasn. Вот они у меня лежат и я их иногда использую. Мне вот очень не понравиться если все минорные обновления компилера начнут его ломать. Или если я не смогу слинковаться с либой из дистриба немного другим компилером, у мнея их вообще 2, clang и gcc, а в репе собиралось одним (причем точно не ими, потмоу что вот они обновились, а все остальное — нет). Понимаете масштаб проблемы?
Так я про это и говорю: если не нужен ABI, не надо модулей, плагинов, шаринга кода/rdata между независимыми приложениями, удобного интерфейса к JIT и прочего — лучше линковать lto, это эффективнее и сделает каждой функции совой оптимальный ABI.
Речь же про кейсы когда он нужен, а для системного языка — это маст хев. Для потенциального заменителя C/C++ — тоже.
Все верно, это не костыль, а совместимость с си. Просто предлагается в либах и там где нужен стабильный ABI — все это использовать всегда. Но не все это в либах делают, и не всем хочется. Потому будут делать по-разному и проблема останется.
Да, я сталкивался с этим. Обновляешь что-то — и какой-то модуль из зависимостей не собирается из-за сишного модуля. Довольно неприятно и бывает трудно исправить.
Не путайте проблемы API и ABI, я говорил только про ABI. API — да, проблема на стороне разработчика библиотеки.
У питона полно проблем с совместимостью, я постоянно сталкиваюсь, и лучше бы чтобы их небыло. К тому-же притон интерпритируемый язык, но просто перекопилит кэш сам, там куда больше API/библиотек совместимость едет.
Ну тут я согласен. Можно тогда язык использовть через си ABI, раз своего нет. Но конкретно у раста это потребует всякие
#[repr(C)]и libc::*, а не все это делают. Язык получается не самостоятельный и это все равно минус. Свой стабильный ABI — это хорошо, или сделать чтобы все нужные конструкции типа#[repr(C)]были автоматом при экспорте в либы\dll\so. Но постойте-ка, это и получился бы совой стабильный ABI.А иначе — все таки перекладывание этой проблемы с языка на разработчика. Не рассчитана либа на си — придется решать. А если все либы рассчитаны на си (как вы предлагаетте, всем так делать) — ну так вот он, свой стабильный ABI, стандартизируем как его свой и проблема решена. А пока этого нет — будут делать и так и так и проблема останется.
Не совсем, это просто менее стабильный ABI нежели си и один из вариантов решения возникаемой от поломок пробелмы. Но благодаря поддержке его стабильности в определенных пределах — люди впринципе этом могут этим пользоваться, и пользуются. Это впринципе зачем нужен ABI. Если он совсем часто ломается — это так-себе ABI, поддержка усложнится и пользваться станут реже, или станут от чего-то отказываться, это однозначная проблема для кейсов где он нужен. Если же впринципе отказаться от поддержки стабильности ABI — ну так это равноценно тому что его нет, соответственно кейсы где он нужен просто не применимы.
Все так. На винде решают проблему, поставляя redist c приложением и держа несколько копий мажорных версий в системе. На лине — поддерживая какую-то минимальную версию stdc++.
Так же на лине теперь доступен вариант и как в винде — указывая разные версии core в flatpak/snap, будем попадать на разные версии stdc++. В системе их тоже может стать несколько, и все еще будем их шарить между приложениями.
Да я вкурсе что такое msvcp. Речь про то что он ставится в систему и будет шариться между всеми приложениями, как stdc++ под линем. Чем не интерфейс не на си? Вот WINAPI — да, там везде си, в .net — уже нет, на маке тоже в основном нет. Но это все не к тому, что си интерфейс нажеднее все равно никто не спорит. Это как раз наглядно показывает что это нужная фича, и сишные интерфейсы часто из-за этого выбирают.
Что COM не С++ я тоже вкурсе, но это и не си, хоть из си и можно работать, из си вообще с чем угодно можно работать.
Нет, на винде ABI у дельфи для dll`ок вполне совместим. Ну то есть вы согласны что ABI иногда нужен, и что когда он долго не ломается — это хорошо?
Вы просто к тому что у других языков это не получится и надо всегда делать обертки на си? Ну хорошо, это же не противоречит тому, что ломать ABI плохо. Просто язык значит никогда не будет самостоятельным и требовать си для кейсов когда нужен ABI, именно по этой причине. И чем чаще происходит поломка ABI — тем более это верно.
Вот только не все спешат бежать делать си обертки для своих библиотек. А как миниум С++ и ObjC/Swift в реальной жизни вполне используют. Под виндой какой-то из стабильных msvcp, под линем stdc++ от какой-то версии и получают шаринг между приложениями и приемлимое время жизни приложения.
Отказ от поддержки ABI по сути будет перекладывание работы с разработчика языка на разработчиков библиотек\приложений для кейсов когда он нужен и он никогда не сможет стать именно заменой C/C++.
Вы опять про все пересобрать. Вы понимаете, что если вы можете все пересобрать, — оно вам не надо. А если Far собран С++, а плагин на дельфи, и его создатель не имеет контроля над сборкой фара, и всех его версий у всех, — то ABI нужно. Да, оно кода-нибудь сломается, но ABI тут всё равно нужен, так что обратная мантра тоже не работает. И чем дольше оно не ломается — тем лучше. В вашем варианте мы просто не делаем плагины фару, всегда пересобираем из какой-то репы те что у вас есть.
И какой вид ни делай, если плагины ломаются очень редко — молодцы; часто ломаются — ну не молодцы, но может не сами девелоперы, а девелоперы их языка и возможно действительно переключиться на сишную прослойку хорошая идея. В общем это плохо как ни крути, может быть оправданным, но плохо и делать это стоит как можно реже. Кейсов где ABI нужен полно.
Как это не видели? В винде msvcp*, это хоть и redist и его обычно с приложением поставляют (хотя от старых студий уже вроде в комплекте, от 6й точно), но оно будет шариться между всеми использующими эту стабильную версию приложениями, и ему нужен ABI. Так же directx redist включают, COM интерфейс это тоже не C.
Макось? Полно не сишных интерфейсов, и что печально — сишные opengl и openal депрекейтят.
На лине тоже firefox использует stdc++ из системы, причем там при сборке конфигурится, какую минимально поддерживать. Есть куча других либ с не сишными интерфейсами.
Но вы абсолютно правы, что си интерфейс — наиболее ABI стабильный. А с++ и другие ломаются куда чаще. Именно потому его все любят, когда нужна совместимость. Именно потому — часто ломать ABI плохо, неважно stdc++, rust или go. Это вызывает проблемы в определенных случаях и их придется решать одним из способов.
Проблема тут следующая: Я не собираю игру тем же компилером что steam runtime. И когда пакую ее во flatpak, я не собираю core, но ссылку на него указываю. Понятия не имею, что там за компилер использовался, но игра работает.
Ну то-есть ABI нужен везде, где надо что-то с чем-то совместить, компоненты, где твое может быть только часть. Поставить third party, собрать что-то один раз и использовать либу, сделать dll\so и экономить юзеру память, плагины к какому-то софту итд. Когда все это не надо — ну да, тут эффективнее lto и статическая линковка, ктож спорит.
Все так: glibc — мало проблем, libstd++ — больше, Boost — еще больше; libicu — не сталкивался. Но это не значит что им не пользуются.
У steam runtime, например, достаточно стабильное API/ABI, в пределах дистра благодаря этому куча кода шарится, даже у flatpak/snap идут ссылки на свои core для этих целей. Есть куча более стабильных библиотек что таких проблем не вызывают. И это будет еще только больше проблем если весь этот мир пересобирать раз в несколько месяцев.
Что вы предлагаете — по сути вообще отказаться от ABI, ну так пожалуйста, линкуйте с lto — нужен будет компилер именно той версии, вот оно полностью сломанное ABI уже есть. Это же не значит что нет случаев, когда надо компоненты делать совместимыми, и хочется чтобы эта система пожила подольше и требовала меньше поддержки.
К слову про производительность. Все последние изменения в stdc++ abi они из-за фич языка, не из-за производительности. Производительность да, это хорошо, и над этим думать надо. Но это редко надо, бесконечность итераций тут не надо для одной архитектуры для стабилизации.
То-есть пользоваться растом исключительно через другой язык? Где таки постарались и нарушения ABI редки?
И чем умеют пользоваться, и какие проблемы у всех возникают? C++ ABI умеют пользоваться единицы и у всех с ним проблемы возникают?
Ну так а вы предлагаете еще чаще эти проблемы сделать, а пользоваться умеют все — скомпилил и какой-то ABI получил. И его желательно не замечать, только чинить если у кого-то где-то сломается, а не ломать все время. Вот чинить да, может и единицы умеют. Посмотрите как это в firefox решается для stdc++, и это при редких изменениях, а при нестабильном — будет вообще кошмар.
Ломать его, конечно, приемлимо в некоторых случаях, например если ни либы ни dll\so не нужны. Но в остальном — чем реже тем лучше.
Ну это да. И это порождает определенные проблемы, из-за этого даже вводят всякие _GLIBCXX_USE_CXX11_ABI, и оно даже реально пригождается в реальной жизни. И вот представим что на это забьют и это все станет регулярным. Раз в 3 месяца пересобираем весь мир, к примеру (а проблем с пересборкой конечно же ни у кого не возникнет). А проприетарщина вообще, кому она нужна? Давайте исходники, либы не принимаем.
Это и gcc/msvc уже очень давно делает, и не только для статик, но и для всех при lto/pgo. ABI он наружу, чтобы статические либы и dll\so не протухали каждые несколько месяцев.