Тема, когда современный компилятор С++, запущенный на свежем дистрибутиве линукс

порождает бинарник с зависимостью от более свежей glibc, чем готов накатить себе админ заказчика. Немного затронута, но не раскрыта. Варианты, которые мы опробовали:
1. собирать на древнем дистрибутиве старым компилятором (ибо новому тоже какая-то нужна glibc не из древних)
2. вручную ковыряться внутри бинарника - искать, за какой новый символ тот зацепился, чтобы убрать
3. запускать собранное ПО в докер-контейнере или еще как-то виртуализовать
4. линковать всё статически (всю толпу, которая есть в проекте)
Может еще какой забыл, но все они в той или иной мере ущербные. Кто-то может предложить более интересное решение? Насколько я понимаю, такого варианта, как в винде - ссыпать всё необходимое в один каталог, ни в каком дистрибутиве Линукса пока что не предлагается. Загрузчик все равно будет изо всех сил пытаться взять старую системную glibc.

https://github.com/wheybags/glibc_version_header

а насколько древняя целевая libc?

а вообще тема подробно раскрыта в https://www.youtube.com/watch?v=Z7WuUhPJ-cU

а чем вариант 4 концептуально отличается от виндового "ссыпать всё в один каталог"?

Уже 4 года не обновлялось 😞

оно сломалось вроде для какой-то более-менее последней glibc, там какие-то новые символы появились для которых просто так версию не переназначить

glibc 2.17 в ALterOS - пока что отпинались, сказав, что 2012 год староват для нас

загрузчик можно тоже таскать с собой и запускать явно ./ld.so my_program

нет, нельзя загрузчик тесно связан с ядром

Самое надёжное решение: собирать с sysroot, в котором будут заголовки и системные .so-шки целевой системы

ну кстати flatpak есть, там glibc своя тащится в рантайме

glibc гарантирует прямую совместимость, софт собранный со старой версией запустится с новой

>> 3. запускать собранное ПО в докер-контейнере или еще как-то виртуализовать Докер — это не виртуализация, так что если есть подходящий базовый контейнер с долгосрочной поддержкой (или вы сами можете такой собрать и поддерживать), то это самый простой и удобный вариант, как по мне

Так, кстати, устроен Android NDK, да и вообще многие кросс-тулчейны

это да, но вроде обсуждаем случай наоборот, когда софт собирается с новой glibc, а запускается со старой

Тут есть проблема, что под старый контейнер может не оказаться новой версии компилятора (в бинарном дистрибутиве). Потому что никто не собрал =)

Лично я в такой ситуации линкую статически, а символы glibc форсирую, как ссылку кидали выше. Меньше динамических зависимостей — меньше проблем

можно, не связан

я раньше использовал эти заголовки, но оно сломалось с какой-то версии

тесно связан с версией libc, так что нужно таскать строго той же версии

Мой личный опыт подсказывает, что собрать (когда это возможно) новый компилятор под старым дистрибутивом сильно проще, чем кросскомпилировать под старый, так что я бы попробовал в начале такой вариант

Там ребята поменяли реализацию CRT, так что только sysroot

Кстати так и делаем. Вполне рабочая схема.

У нас уже куча докер-образов с разными версиями и источниками б-к, мы в них тесты гоняем, довольно успешно. Но overhead у докера все же ненулевой.

вопрос определения, Таненбаум например склонен виртуализацией называть примерно что угодно

>> Но overhead у докера все же ненулевой Под какой ОС? Потому что под Linux запуск в контейнере принципиально не отличается от нативного запуска процесса

Когда я одновременно запускаю 26 нативных процессов с тестами в Linux, они заполняют собой примерно 32 GB ОЗУ. Аналогичные 26 докер-образов - примерно 48 GB. И где-то 10% медленнее. Но всё равно, лично мне этот вариант очень нравится тем, что почти нет причин для отказов.

pthread переехал в glibc, в частности, тоже сталкивался, пришлось костылить

В контейнере мы запускаем наше ПО, не компилятор.

Рост памяти объясним — в каждом контейнере своя версия рантайма/зависимостей, которые, скорее всего, не удаётся шарить между процессами. Но это буквально то, зачем нужен докер. Скорее всего, запустив 26 процессов в одном образе, ваш результат не будет отличаться от нативного запуска. И скорость... Наверное, падение производительности связано как раз с тем, что ресурсы не шарятся, чем с накладными расходами от докера

посмотрел свои записи, для меня оно сломалось на glibc 2.33, там что-то намутили с новыми символами для stat, fstat

Там тоже ломалось, но чинилось относительно легко

А вот если бы существовала headers-only версия стандартной библиотеки то подобных проблем просто не существовало бы - просто скачиваешь исходники стандартной библиотеки в репозиторий с проектом и дальше просто инклудишь нужный хедер, например #include "./libs/std/vector" и всё - теперь можно юзать в коде std::vector и никаких проблем со сборкой, линковкой, конфликтов с предустановленными в ОС бинарниками и т.д

Плюс это еще работало бы быстрее так как компилятор либо сможет либо заинлайнить функции стандартной библиотеки прямо в код либо заоптимизировать вызовы (так как ему не нужно придерживаться ABI)

И сразу —shared память

?

И ещё ОС тоже собирать вместе с приложением. Зачем тратить ресурсы на call'ы в библиотеке?

Общая для разных приложений

и в чем проблема?

Ну так она больше не будет общей

Да вообще все надор в constexpr считать!

вы изоберели gentoo!

А я кстати всерьез рассматриваю такой вариант. Если у меня на сервере будет работать только одно приложение (база данных) то зачем спрашивается тратится на сискол вызовы (да еще с переключением контекста) если можно статически слинковать приложение с ядром линукса (когда компилятор сможет даже заинлайнить сисколы прямо в код) ?

например, чтобы при краше приложения по-прежнему иметь работоспособную систему…

чтобы если упало, так точно ничего не собрать: ни логи, ни корку, ни метрики

Не забудьте про свой ASIC под конкретную задачу, выйдет ещё эффективнее!)

Опять 25. Вам не надоела эта тема? Дайте номер вашего дилера — я хочу такой же травы!

компиляция и статическая линковка в FPGA битстрим

Кстати я тут недавно смотрел на возможности fpga-решений для реализации базы данных. К сожалению ни одна fpga плата не поддерживает то количество dimm-слотов оперативной памяти которую поддерживают современные x64 материнки. Вот например такая материнка (https://www.supermicro.com/en/products/motherboard/h13ssh) поддерживает 24 планки памяти (а если несколько сокетов то вообще 64 планки - https://www.supermicro.com/en/products/motherboard/x13qeh+) Ничего подобного среди fpga-плат не найти.

Если всерьез рассматриваешь, то в случае когда на сервере будет крутиться только одно приложение - линукс не нужен. Любая оська не нужна.

Тебе не нужно ядро линукса в таком случае, includeos хватит.