Здравствуйте, Мёртвый Даун, Вы писали:
МД>Интересная статейка, мне показалось есть что обсудить.
Мне интересно, а ABI в С++ когда-нибудь был?
И почему я про него не слышал?
Мне всегда казалось, что ABI в С++ всегда был implementation specific.
И как можно сломать, то чего нет?
Для чего я тогда реализовывал проект beautiful capi — https://github.com/PetrPPetrov/beautiful-capi ?
Для чего Microsoft придумывала технологию COM? Для чего нужен IFX COM? И куча других аналогов кросплатформенных COM?
Если ABI есть в С++, то программу можно скомпилировать при помощи Visual C++, и она будет использовать С\С++ Runttime libraries- DLL-ки msvcr__.dll и
прочие (именование зависит от версии студии), то ей можно поднусуть glibc.dll из MinGW просто переименовав DLL-ку? И она будет работать?
Или другой версии студии?
Здравствуйте, GhostCoders, Вы писали:
GC>Мне интересно, а ABI в С++ когда-нибудь был? GC>И почему я про него не слышал?
Речь, видимо, идет о том, что некоторые изменения в языке/библиотеке не оставляют даже теоретической возможности сохранить совместимость на уровне ABI. С учетом того, что практические реализации языка плевать хотели на эту совместимость, все это довольно смешно и умозрительно.
GC>Мне всегда казалось, что ABI в С++ всегда был implementation specific.
Но хоть бы внутри одной имплементации поддерживали совместимость. Хотя бы на уровне, когда можно экспортировать из динамически загружаемой библиотеки C++'ные классы (а не pure C функции), и не бояться, что перекомпиляция программы другой версией компилятора сломает ее совместимость с динамическими библиотеками.
Здравствуйте, netch80, Вы писали:
N>Практически единственный недостаток динамических библиотек — это что с ними код чуть медленнее, из-за подключения подгружаемых функций через санки. И то можно делать без них. N>Ну и ещё с ними тотальный LTO не получается. N>Остальное — в плюс.
Основной недостаток динамических библиотек — это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, и тогда нет смысла делать их динамическими, или всегда есть риск, что какое-то сочетание версии программы с версией библиотеки будет не работать. Причем без предупреждения.
На днях в Праге комитет по стандартизации С++ провел ряд опросов по вопросу изменения ABI, и в конечном счете было решено ничего в нем не менять. Аплодисментов в зале слышно не было.
Я думаю, мы не осознавали полностью те последствия, которое повлечет за собой данное решение, и я не верю, что оно в принципе может положительно сказаться на развитии языка.
...
Почему мы должны сломать ABI
Прежде всего, есть несколько полезных изменений в реализации стандартной библиотеки, которые можно внедрить, если нарушить текущий ABI:
— Сделать ассоциативные контейнеры (намного) быстрее
— Ускорить работу std::regex (На данный момент быстрее запустить PHP и выполнить на нем поиск по регулярному выражению, чем использовать стандартный std::regex)
— Некоторые изменения в std::string, std::vector, а также в разметке других контейнеров
— Единство интерфейса классов: на данный момент некоторые их реализации намеренно не соответствуют единому интерфейсу в угоду стабильности ABI
...
В какой версии C++ ждать изменений
Очевидный недостаток всех этих опросов заключается в том, что мы так и не определились, когда именно мы хотим сломать ABI.
в C++23? Нет, уже точно нет.
в C++26? Часть людей намерены голосовать за, но другая часть скорее всего проголосует за C++41 или за то время, когда они уйдут на пенсию и им не придется поддерживать свой текущий проект. Один из вопросов просто упоминал C++-какой-то; очень удобно!
Я глубоко убежден, что решение не ломать ABI в 23-м году — это самая большая ошибка, которую когда-либо делал комитет. И я знаю, что некоторые люди верят в обратное.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Igore, Вы писали:
I>Мне даже интересно, у кого в проекте используется dll, so, dylib собраный не вами а скачаный откуда-то?
По большей части собираем из исходников. Однако есть одна такая, с закрытыми исходниками, ее используем скачанную — https://www.opendesign.com/
И еще сами свою библиотеку даем своим заказчикам в собранном виде (тоже закрытая).
Но свою обернули при помощи beautiful capi — https://github.com/PetrPPetrov/beautiful-capi
Получается такая standalone DLL, из зависимостей на Windows по большому счёту только KERNEL32.DLL,
C\C++ Runtime library влинкован статически (/MT ключик), API самой DLL — только Сишный, используются типы unit32_t, uint8_t
и только такие, исключения наружу не проскакивают.
У клиента есть выбор — использовать или C-API, либо использовать С++ врапперы (набор header only классов; реализованных при помощи С++ 98),
которые реализованы поверх вызовов нашего C-API.
Внутри наша библиотека использует С++ 14 (построенна при помощи Visual Studio 2019),
а вот клиент может ее использовать хоть в Visual C++ 6.0 (C++ 98), и какой-то другой компилятор (Clang для Windows, GCC из MinGW и т.д.).
Причем клиент может использовать любые ключи компиляции для своего приложения —
нет никакой необходимости в соответствии ключей компиляции его приложения и нашей библиотеки.
В общем часть людей хочет сделать новую STL, по сути Boost или даже более толстый фреймворк. Но фишка STL в том, что она как правило распространяется вместе с компилятором языка.
1) Готовы ли производители компиляторов выпускать все хотелки ждунов?
2) А ничего, что тот, кого будет не устраивать новая STL автоматически останется на предыдущих версиях языка C++?
3) Ещё не нужно забывать, что некоторые разработчики компиляторов забивают на стандарт, а другие тщательно его соблюдают и поддерживают все предыдущие версии. Чем больше выдумают, тем больше у первых причин будет забивать на стандарт ещё больше, а у вторых работы по поддержанию всех версий.
4) Заблуждение, что создав свою супермега версию стандартной библиотеки, все разработчики тут же отринут свои велосипеды и перейдут на неё. STL как это ни странно всё равно чужеродна другим разработчикам начиная с имён и кончая реализацией.
В общем пусть делают, если хотят. Лично я уверен, что за глаза хватило бы и ISO/IEC 14882:2003, а то и вовсе ISO/IEC 14882:1998. А то чего не хватает, добирать сторонними библиотеками. Но мне новые стандарты и сейчас нисколько не мешают, поскольку я их не использую. У C++ не такая политика, чтобы поломать все предыдущие стандарты и поддерживать только самое новое, потому можно на всё это забить.
Здравствуйте, Мёртвый Даун, Вы писали:
МД>Интересная статейка, мне показалось есть что обсудить.
А чего тут обсуждать, я пока ниразу не встречал использование бинарников в том виде каком они есть, всегда делается сборка библиотек с попыткой использовать одни и теже ключи компиляции, поэтому сломают ABI или не сломают, мне работы не уменьшится. Мне даже интересно, у кого в проекте используется dll, so, dylib собраный не вами а скачаный откуда-то?
Им придётся расширять стандартную библиотеку и ломать как ABI так и API. Иначе интерес к языку уйдёт.
Библиотеку придётся расширять так как просто голый язык уже нафиг никому не нужен, каким бы хорошим он ни был.
API — чтобы повычищать тот идиотизм, что уже напринимали.
ABI — чтобы наконец-то привести "модули" (да-да, они ещё будут меняться) к адекватному состоянию.
Уже был такой период "стабильности", что спешно пришлось и с++11 и дальнейшие версии принимать, так как народ повалил на другие языки, которые активно развивались.
И если язык не развивать — то он превратится в очередной Cobol с рабочей силой в два с половиной деда на пол планеты.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, netch80, Вы писали:
Pzz>это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, Pzz>и тогда нет смысла делать их динамическими
Ну например разделяемые библиотеки позволяют прятать символы, с помощью
`__attribute__ ((visibility ("hidden")))` или его аналога.
Это позволяет прятать статические библиотеки внутри динамической,
не показывая их наружу, то есть например иметь две разные
версии одной библиотеки с одинаковыми именами функций, если эти две разные библиотеки
являются частями разных разделяемых библиотек.
МД>На днях в Праге комитет по стандартизации С++ провел ряд опросов по вопросу изменения ABI, и в конечном счете было решено ничего в нем не менять.
Я всегда говорил, что динамические библиотеки — это зло в чистом виде, но вот о том, что они могут препятствовать развитию C++ не думал. Практика показывает, что если есть две версии бесплатной программы: со статической линковкой и с динамическими модулями, то статическая версия всегда выигрывает по количеству инсталлированных копий. Я вообще не вижу причин использовать бинарные модули, кроме лицензионных.
Однако, в комментариях там замечают, что автор не прав в том смысле, что он предполагает (неявно) поломку API, а не ABI. Вот API нельзя ломать категорически.
Так же в комментариях верно подмечено, что Qt ломает своё ABI каждый мажорный релиз — и всё хорошо.
Здравствуйте, Pzz, Вы писали:
Pzz>Основной недостаток динамических библиотек — это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, и тогда нет смысла делать их динамическими
Плагины, например, могут быть только в динамических.
Для динамики можно сделать отложенную загрузку.
В динамических библиотеках можно хранить реализации, собранные для разных архитектур процессоров.
В динамических библиотеках можно прятать закрытый код.
И т.д.
Здравствуйте, Pzz, Вы писали:
N>>Практически единственный недостаток динамических библиотек — это что с ними код чуть медленнее, из-за подключения подгружаемых функций через санки. И то можно делать без них. N>>Ну и ещё с ними тотальный LTO не получается. N>>Остальное — в плюс.
Pzz>Основной недостаток динамических библиотек — это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, и тогда нет смысла делать их динамическими, или всегда есть риск, что какое-то сочетание версии программы с версией библиотеки будет не работать.
Да, риск есть. Например, вдруг какая-то функция Windows перестанет работать. Ядро ведь для юзерленда оно, по сути, динамическая библиотека, с линковкой через сисколлы, или через библиотеки типа user32.dll.
И мы всё равно миримся с этим, потому что альтернативы нет, не тащить ведь полную ОС за своим приложением.
Где-то тащат (аплайансы типа банкоматов), но ты у себя ведь так не делаеш?
Pzz> Причем без предупреждения.
Насколько без предупреждения? Если речь о замене мажорной версии системы со всеми библиотеками — то при этой замене, когда идёт проблема, всегда предупреждают: надо пересобрать, у нас отменена libvasya, применяйте libpetya или тащите libvasya с собой.
Если о минорах — то не должно несовместимо меняться.
Но польза от закрытия дыр и багов в стандартных библиотеках до сих пор заметно превышала недостатки такой возможной несовместимости.
Здравствуйте, Pzz, Вы писали:
N>>Насколько без предупреждения? Если речь о замене мажорной версии системы со всеми библиотеками — то при этой замене, когда идёт проблема, всегда предупреждают: надо пересобрать, у нас отменена libvasya, применяйте libpetya или тащите libvasya с собой. N>>Если о минорах — то не должно несовместимо меняться. N>>Но польза от закрытия дыр и багов в стандартных библиотеках до сих пор заметно превышала недостатки такой возможной несовместимости.
Pzz>Я помню времена, когда программы, написанные на Qt, вдруг неожиданно начинали глючить при незначительной смене версии этой самой Qt. Причем именно глючить. Лучше бы они запускаться отказывались, желательно указав пальцем на причину.
Давно это было? По-моему, я уже лет 10 не слышал таких чудес.
МД>>На днях в Праге комитет по стандартизации С++ провел ряд опросов по вопросу изменения ABI, и в конечном счете было решено ничего в нем не менять.
BFE>Я всегда говорил, что динамические библиотеки — это зло в чистом виде, но вот о том, что они могут препятствовать развитию C++ не думал.
Динамические библиотеки не препятствуют развитию C++.
Если библиотека подложки меняется с несовместимой сменой API, то перекомпилировать под неё нужно одинаково и в случае статических, и в случае динамических библиотек.
BFE> Практика показывает, что если есть две версии бесплатной программы: со статической линковкой и с динамическими модулями, то статическая версия всегда выигрывает по количеству инсталлированных копий. Я вообще не вижу причин использовать бинарные модули, кроме лицензионных.
Какой-то странный переход к бинарным модулям от динамических библиотек.
Практически единственный недостаток динамических библиотек — это что с ними код чуть медленнее, из-за подключения подгружаемых функций через санки. И то можно делать без них.
Ну и ещё с ними тотальный LTO не получается.
Остальное — в плюс.
BFE>Однако, в комментариях там замечают, что автор не прав в том смысле, что он предполагает (неявно) поломку API, а не ABI. Вот API нельзя ломать категорически.
Да, непонятно, почему вообще речь про ABI, если фактор типа возвращаемого значения метода это API.
Здравствуйте, GhostCoders, Вы писали:
GC>Здравствуйте, Мёртвый Даун, Вы писали:
МД>>Интересная статейка, мне показалось есть что обсудить.
GC>Мне интересно, а ABI в С++ когда-нибудь был?
Но всякие трюки типа pimpl, который использует Qt для STL явно не подойдут.
GC>Если ABI есть в С++, то программу можно скомпилировать при помощи Visual C++, и она будет использовать С\С++ Runttime libraries- DLL-ки msvcr__.dll и GC>прочие (именование зависит от версии студии), то ей можно поднусуть glibc.dll из MinGW просто переименовав DLL-ку? И она будет работать? GC>Или другой версии студии? GC>Да такого ни в жизнь не будет!
Но здесь я думаю конечно разговор о тех системах где используются
разделяемые, общие для все системы библиотеки с С++ ABI.
Здравствуйте, Igore, Вы писали:
I>А чего тут обсуждать, я пока ниразу не встречал использование бинарников в том виде каком они есть, всегда делается сборка библиотек с попыткой использовать одни и теже ключи компиляции, поэтому сломают ABI или не сломают, мне работы не уменьшится. Мне даже интересно, у кого в проекте используется dll, so, dylib собраный не вами а скачаный откуда-то?
А если этот so приходит со стандартным пакетом операционной системы, это считается?
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Pzz, Вы писали:
Pzz>>Основной недостаток динамических библиотек — это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, и тогда нет смысла делать их динамическими
N>Плагины, например, могут быть только в динамических.
И как частный случай плагинов — использование нескольких языков программирования.
Например Java/Python/php/C# вызывают C/C++ код, тогда придется собрать свой код в виде
разделяемой библиотеки.
Здравствуйте, Igore, Вы писали:
I>Здравствуйте, Мёртвый Даун, Вы писали:
МД>>Интересная статейка, мне показалось есть что обсудить.
I>А чего тут обсуждать, я пока ниразу не встречал использование бинарников в том виде каком они есть, всегда делается сборка библиотек с попыткой использовать одни и теже ключи компиляции, поэтому сломают ABI или не сломают, мне работы не уменьшится. Мне даже интересно, у кого в проекте используется dll, so, dylib собраный не вами а скачаный откуда-то?
у меня солянка из so/dll разных компиляторов, часть я даже и не слышал вообще в зависимости от платформы, но легко (пока) решается тем, что врапперы делаются над чистым С, плюсами тами и не пахнет, боли не хочется.
Здравствуйте, Pzz, Вы писали:
Pzz>А если этот so приходит со стандартным пакетом операционной системы, это считается?
Думаю, что считается. Однако, если вы собрали программу на одном дистрибутиве Linux,
то будете ли тащить этот so в другой дистрибутив Linux, или будете полагать (или требовать у пользователя установить недостающий пакет),
и данный so на новом дистрибутиве будет нужной версии и будет ABI-совместим с вашей программой?
Просто я как-то часто сталкивался со случаями, когда надо установить какую-то программу (особенно на CentOS)
и она скачиваетя в бинарной форме (нет исходников, закрытые, или даже исходники есть, но собирать влом),
и вот этот готовый бинарник программы требует более новой версии GLIBC, а его в моем дистрибутиве (был CentOS 6.x) его нет.
Я пытался собрать GLIBC — тот еще гемморой, проще дистрибутив Linux поменять.
Я к тому, что Linux и Windows — разные миры. В Linux все библиотеки используются из стандартных пакетов, в Windows — обычно все тащат с собой, свое.
Но в Linux есть проблема разных дистрибутивов (не всегда в нужном дистрибутиве данный пакет будет присутствовать в списке стандартных, часто присутствует, но все же бывает
иногда и нет), еще и GLIBC часто присутствует один для всех программ и он системный.
Такое вот чувство, что это линуксоиды С++-шники панику поднимают — у них он (ABI) присутствует, есть что терять.
Здравствуйте, GhostCoders, Вы писали:
GC>Я к тому, что Linux и Windows — разные миры. В Linux все библиотеки используются из стандартных пакетов, в Windows — обычно все тащат с собой, свое. GC>Но в Linux есть проблема разных дистрибутивов (не всегда в нужном дистрибутиве данный пакет будет присутствовать в списке стандартных, часто присутствует, но все же бывает GC>иногда и нет), еще и GLIBC часто присутствует один для всех программ и он системный.
Есть ещё такие [censored], как snapʼы. Я вот на VScode посмотрел — он тащит за собой весь юзерланд, включая libc.
Здравствуйте, Pzz, Вы писали:
Pzz>Основной недостаток динамических библиотек — это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, и тогда нет смысла делать их динамическими
Почему? Среди возможных причин: плагины и лицензии.
Pzz>или всегда есть риск, что какое-то сочетание версии программы с версией библиотеки будет не работать. Причем без предупреждения.
А где в реальности кроме линуха есть такое?
Здравствуйте, netch80, Вы писали:
N>Да, риск есть. Например, вдруг какая-то функция Windows перестанет работать. Ядро ведь для юзерленда оно, по сути, динамическая библиотека, с линковкой через сисколлы, или через библиотеки типа user32.dll. N>И мы всё равно миримся с этим, потому что альтернативы нет, не тащить ведь полную ОС за своим приложением. N>Где-то тащат (аплайансы типа банкоматов), но ты у себя ведь так не делаеш?
Вообще говоря, я одно время таскал с собой Virtual Box со слепками систем для работы. Т.е. под каждый Toolchain, для каждого отдельного target-девайса, есть свой слепок конкретной системы с инсталированными специфичными для таргета инструментами. Да и сейчас, я не устанавливаю на домашней системе программы, если не собираюсь ими пользоваться более одного раза, а делаю слепок в Virtual Box и в нём устанавливаю ту программу, что хочу посмотреть...
Таскают с собой все файлы не только для банкоматов. Есть целый набор инструментов, для решения этой задачи.
Application Isolation
Eliminate application conflicts by isolating applications from each other and the underlying OS into a single executable file that can be easily deployed to many endpoints, independently or with App Volumes.
Здравствуйте, Skorodum, Вы писали:
Pzz>>Основной недостаток динамических библиотек — это то, что либо у тебя программа распостраняется вместе со всеми своими библиотеками, и тогда нет смысла делать их динамическими S>Почему? Среди возможных причин: плагины и лицензии.
Я говорю про технические причины, конечно.
Pzz>>или всегда есть риск, что какое-то сочетание версии программы с версией библиотеки будет не работать. Причем без предупреждения. S>А где в реальности кроме линуха есть такое?
В венде сдались, и теперь программы сами приносят с собой все свои запчасти. Поэтому сколько у тебя в венде есть програм, столько у тебя есть копий sqlite, потому что все используют sqlite, и все приносят ее с собой. И половина програм приносит копию Qt. А у меня в линихе один экземпляр sqlite и один экземпляр Qt.
Специальное исключение — системные библиотеки и .Net runtime. Про системные библиотеки предполагается, что они в состоянии быть сами с собой совместимыми, .Net пытается заполнить твой диск под завязку многочисленными версиями рантайма, потому что полагаться на совместимость версий никто особо не рискует.
В принципе, это бардак.
Как устроена жизнь в макакосе, я особо не знаю, но подозреваю, что ближе к венде.
Здравствуйте, Pzz, Вы писали:
Pzz>В венде сдались
Вроде никогда и не пытались.
Pzz>В принципе, это бардак.
И все уже привыкли (смайлик по вкусу)
Pzz>Как устроена жизнь в макакосе, я особо не знаю, но подозреваю, что ближе к венде.
Именно.
Здравствуйте, Pzz, Вы писали:
Pzz>В венде сдались, и теперь программы сами приносят с собой все свои запчасти. Поэтому сколько у тебя в венде есть програм, столько у тебя есть копий sqlite, потому что все используют sqlite, и все приносят ее с собой. И половина програм приносит копию Qt. А у меня в линихе один экземпляр sqlite и один экземпляр Qt.
На самом деле у тебя до чёрта экземпляров Sqlite, потому что её очень много кто влинковал к себе цельным сишником. Но это исключение, её не просто легко так влинковать, её явно рекомендуют. А вот других таких очень мало.
Pzz>Специальное исключение — системные библиотеки и .Net runtime. Про системные библиотеки предполагается, что они в состоянии быть сами с собой совместимыми,
"Предполагается" — это мощно сказано вот и имеем, что оно якобы обеспечивается, потому что просто нет иного выхода, как верить MS.
Здравствуйте, netch80, Вы писали:
N>Насколько без предупреждения? Если речь о замене мажорной версии системы со всеми библиотеками — то при этой замене, когда идёт проблема, всегда предупреждают: надо пересобрать, у нас отменена libvasya, применяйте libpetya или тащите libvasya с собой.
И много пользователей твоего софта знают, что такое "пересобрать" и вообще хоть слово в этой белиберде понимают?
N>Если о минорах — то не должно несовместимо меняться.
А если софт пишут без всякого семвера?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, netch80, Вы писали:
Pzz>>Специальное исключение — системные библиотеки и .Net runtime. Про системные библиотеки предполагается, что они в состоянии быть сами с собой совместимыми,
N>"Предполагается" — это мощно сказано вот и имеем, что оно якобы обеспечивается, потому что просто нет иного выхода, как верить MS.
Как известно, "согласие есть продукт при полном непротивлении сторон". Легко, конечно, валить все на MS. Но мне кажется, граждане, которые сами нарушают контракт по имени "документированный API системы", путем использование недокоментированных особенностей этого API (а таких в вендовом мире чуть менее, чем все), им грех жаловаться, что очередной апдейт системы чего-нибудь им сломал.
Здравствуйте, Skorodum, Вы писали:
Pzz>>В венде сдались S>Вроде никогда и не пытались.
Я помню те дивные времена, когда каждая программа, которая чего-нибудь там делала с CD-писалкой, считала своим долгом принести соответствующую DLL-ку с собой, и плюхнуть ее на системное место. А поскольку все версии этой DLL-ки были слегка несовместимыми, то попутно она ломала все прочие программы, которые рассчитывали на определенную версию этой DLL-ки. Ну и плюс Windows Update добавлял свою долю неопределенности в этот процесс.
Pzz>>В принципе, это бардак. S>И все уже привыкли (смайлик по вкусу)
Если вас трамвай задавит,
вы конечно вскрикнете,
раз задавит, два задавит,
а потом привыкнете.
Здравствуйте, netch80, Вы писали:
Pzz>> Причем без предупреждения.
N>Насколько без предупреждения? Если речь о замене мажорной версии системы со всеми библиотеками — то при этой замене, когда идёт проблема, всегда предупреждают: надо пересобрать, у нас отменена libvasya, применяйте libpetya или тащите libvasya с собой. N>Если о минорах — то не должно несовместимо меняться. N>Но польза от закрытия дыр и багов в стандартных библиотеках до сих пор заметно превышала недостатки такой возможной несовместимости.
Я помню времена, когда программы, написанные на Qt, вдруг неожиданно начинали глючить при незначительной смене версии этой самой Qt. Причем именно глючить. Лучше бы они запускаться отказывались, желательно указав пальцем на причину.
Здравствуйте, Nuzhny, Вы писали:
N>Плагины, например, могут быть только в динамических.
Нынче модны плугины, работающие через какой-либо RPC.
N>Для динамики можно сделать отложенную загрузку.
Можно.
N>В динамических библиотеках можно хранить реализации, собранные для разных архитектур процессоров.
И в статике можно (fat binaries есть везде, кроме Линукса).
Здравствуйте, B0FEE664, Вы писали:
N>>Да, риск есть. Например, вдруг какая-то функция Windows перестанет работать. Ядро ведь для юзерленда оно, по сути, динамическая библиотека, с линковкой через сисколлы, или через библиотеки типа user32.dll. N>>И мы всё равно миримся с этим, потому что альтернативы нет, не тащить ведь полную ОС за своим приложением. N>>Где-то тащат (аплайансы типа банкоматов), но ты у себя ведь так не делаеш?
BFE>Вообще говоря, я одно время таскал с собой Virtual Box со слепками систем для работы. Т.е. под каждый Toolchain, для каждого отдельного target-девайса, есть свой слепок конкретной системы с инсталированными специфичными для таргета инструментами.
Это ты про разработку. Конечному юзеру ведь ты не предложишь так делать, пошлёт нафиг?
Ну разве что корпоратов заставить, слегка похрустев их косточками, им деваться некуда.
BFE>Таскают с собой все файлы не только для банкоматов. Есть целый набор инструментов, для решения этой задачи.
BFE>VMware ThinApp например:
Есть, да. Те же контейнеры, вид сбоку. ОС всё равно не заменяют. Ты не сможешь внутрь такого зверя впихнуть те же user32.dll, ntdll.dll и прочие — в каждой новой Windows даже сисколлы все перенумерованы заново по алфавиту — в отличие от Linux, где как Торвальдс стукнул кулаком по столу "We don't break userland!", так и сохраняются вызовы типа setuid16, которые уже 20 лет никому не нужны.
Просто граница в другом месте проведена.
По конструктиву: я хотел сказать ровно то, что качество сохранения зависимостей зависит только от желания авторов этих зависимостей (в случае дистрибутива в соавторы тут попадают и сборщики пакетов). Да, можно это лечить тасканием всего с собой, но только до определённой степени, и с известными проблемами (всё обновление берёшь на себя).
Здравствуйте, Ops, Вы писали:
N>>Насколько без предупреждения? Если речь о замене мажорной версии системы со всеми библиотеками — то при этой замене, когда идёт проблема, всегда предупреждают: надо пересобрать, у нас отменена libvasya, применяйте libpetya или тащите libvasya с собой.
Ops>И много пользователей твоего софта знают, что такое "пересобрать" и вообще хоть слово в этой белиберде понимают?
А при чём тут пользователи, когда это проблема поставщика целевой софтины? Не подменяй.
N>>Если о минорах — то не должно несовместимо меняться.
Ops>А если софт пишут без всякого семвера?
То таких бьют по наглой рыжей морде за первый случай и изгоняют из клуба за второй (ну или хотя бы забирают на себя упаковку). Но с приходом ELF symbol versioning необходимость жёсткой нумерации заметно упала.
Да, я читал рядом про Qt. Но и они достаточно осторожны, чуть дадут слабину — GNU стек их вытеснит.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Специальное исключение — системные библиотеки и .Net runtime. Про системные библиотеки предполагается, что они в состоянии быть сами с собой совместимыми,
N>>"Предполагается" — это мощно сказано вот и имеем, что оно якобы обеспечивается, потому что просто нет иного выхода, как верить MS.
Pzz>Как известно, "согласие есть продукт при полном непротивлении сторон". Легко, конечно, валить все на MS. Но мне кажется, граждане, которые сами нарушают контракт по имени "документированный API системы", путем использование недокоментированных особенностей этого API (а таких в вендовом мире чуть менее, чем все), им грех жаловаться, что очередной апдейт системы чего-нибудь им сломал.
Ну вот как можно сочетать "грех жаловаться" и "чуть менее, чем все"?
Здравствуйте, netch80, Вы писали:
Pzz>>Я помню времена, когда программы, написанные на Qt, вдруг неожиданно начинали глючить при незначительной смене версии этой самой Qt. Причем именно глючить. Лучше бы они запускаться отказывались, желательно указав пальцем на причину.
N>Давно это было? По-моему, я уже лет 10 не слышал таких чудес.
Здравствуйте, netch80, Вы писали:
Pzz>>Как известно, "согласие есть продукт при полном непротивлении сторон". Легко, конечно, валить все на MS. Но мне кажется, граждане, которые сами нарушают контракт по имени "документированный API системы", путем использование недокоментированных особенностей этого API (а таких в вендовом мире чуть менее, чем все), им грех жаловаться, что очередной апдейт системы чего-нибудь им сломал.
N>Ну вот как можно сочетать "грех жаловаться" и "чуть менее, чем все"?
А что, по-твоему, если все воруют, то воровство уже и не преступление вовсе?
Здравствуйте, netch80, Вы писали:
BFE>>Вообще говоря, я одно время таскал с собой Virtual Box со слепками систем для работы. Т.е. под каждый Toolchain, для каждого отдельного target-девайса, есть свой слепок конкретной системы с инсталированными специфичными для таргета инструментами.
N>Это ты про разработку. Конечному юзеру ведь ты не предложишь так делать, пошлёт нафиг? N>Ну разве что корпоратов заставить, слегка похрустев их косточками, им деваться некуда.
Ну в принципе, эти новомодные snap'ы, в которые теперь предполагается упаковывать линуксные программы, это примерно оно и есть. Только в красивом фантике и с модным словом на этикетке.
Здравствуйте, Skorodum, Вы писали:
S>А где в реальности кроме линуха есть такое?
Это есть везде, но только не в линуксах и OСях, в которых запилили такие же пакетные менеджеры, как в линуксах. Только в линуксах ты можешь паковать свою прогу в пакет, указывая какую именно версию какой либы менеджер должен подтянуть в систему при установке пакета. В виндах такого и билзко нет, именно там проблема неработающих прог с разными версиями либ.
Здравствуйте, smeeld, Вы писали:
S>Это есть везде, но только не в линуксах и OСях, в которых запилили такие же пакетные менеджеры, как в линуксах. Только в линуксах ты можешь паковать свою прогу в пакет, указывая какую именно версию какой либы менеджер должен подтянуть в систему при установке пакета.
Где есть полноценные пакетные менеджеры с зависимостями и где пользователи устанавливают большую часть софта через эти менеджеры?
S>В виндах такого и билзко нет, именно там проблема неработающих прог с разными версиями либ.
В виндах такой проблемы вообще нет, потому что там всегда "все свое ношу с собой".
Здравствуйте, Skorodum, Вы писали:
S>Где есть полноценные пакетные менеджеры с зависимостями
Во всех промышленных дистрах линукса, а также во всех БЗДях (pkgsrc).
>и где пользователи устанавливают большую часть софта через эти менеджеры?
Все пользователи промышленных дистров линукса ставят софт из репозиториев, внешних общих, или собственных закрытых, чкерез стандартные пакетные менеджеры. Любая прога заворачивается в пакет с установкой всех нужных зависимостей, именно таких, которые имеются либо в внешних общих репозиториях, либо в своих закрытых. Если кто-то делает не так, то он просто непрофессиональный ламер, которого к линуксам близко подпускать нельзя.
>В виндах такой проблемы вообще нет, потому что там всегда "все свое ношу с собой".
Ясно. Самый тупой способ из всех существующих. Специально для дебилов.
Здравствуйте, smeeld, Вы писали:
S>Во всех промышленных дистрах линукса, а также во всех БЗДях (pkgsrc).
Мыло-мочало, начинай с начала... Вопрос был следующий
BSD — зачет, на этом можно было бы и остановиться.
>>и где пользователи устанавливают большую часть софта через эти менеджеры? S> Все пользователи промышленных дистров линукса ставят софт из репозиториев, внешних общих, или собственных закрытых, чкерез стандартные пакетные менеджеры. Любая прога заворачивается в пакет с установкой всех нужных зависимостей, именно таких, которые имеются либо в внешних общих репозиториях, либо в своих закрытых. Если кто-то делает не так, то он просто непрофессиональный ламер, которого к линуксам близко подпускать нельзя.
Это прекрасно, что вы делитесь такими сакральными знаниями, но вопрос был в контексте "кроме линуха"...
>>В виндах такой проблемы вообще нет, потому что там всегда "все свое ношу с собой". S>Ясно. Самый тупой способ из всех существующих. Специально для дебилов.
Кто-то нить разговора вообще потерял...
Pzz>или всегда есть риск, что какое-то сочетание версии программы с версией библиотеки будет не работать. Причем без предупреждения.
А где в реальности кроме линуха есть такое?
Из этого контекста следует, что во этого:
есть риск, что какое-то сочетание версии программы с версией библиотеки будет не работать. Причем без предупреждения
Здравствуйте, netch80, Вы писали:
BFE>>Вообще говоря, я одно время таскал с собой Virtual Box со слепками систем для работы. Т.е. под каждый Toolchain, для каждого отдельного target-девайса, есть свой слепок конкретной системы с инсталированными специфичными для таргета инструментами. N>Это ты про разработку. Конечному юзеру ведь ты не предложишь так делать, пошлёт нафиг?
Хотя даже сейчас, некоторые продвинутые пользователи ходят на пиратские и порно сайты только из-под виртуальных систем, при текущем положении дел — пошлёт; но теоретически за этим есть вероятное будущее: каждый браузер — своя виртуальная машина в которую подкачивается и исполняются бинарники прямо с сайта. Каждая вкладка — своя виртуальная машина, со своими экзешниками и бинарными библиотеками. Сейчас такое пытаются сделать, но только на базе интерпретаторов. Если кто-то решится на скрещивание виртуализатора с браузером, то он вполне может преуспеть. Все необходимые технологии сейчас уже есть, так что вопрос только в менеджерских амбициях и способнастях бизнесов договорится между собой (по лицензиям). Сомневаюсь, что смогут договориться.
(тоже закрытая).
он везде 
солянка из so/dll разных компиляторов, часть я даже и не слышал вообще 
в зависимости от платформы, но легко (пока) решается тем, что врапперы делаются над чистым С, плюсами тами и не пахнет, боли не хочется.
