Насколько хорошая практика статически линковать libgcc?

она все равно тянет кучу всего динамически. так что смысла нет.

А мне остальное не слишком важно, надо на debian buster притащить gcc-9+ из bullseye. Целевая платформа для деплоя тот же buster. gcc-9 притащит с собой уже libgcc-10+. Стандартная библиотека вроде не конфликтует. Вот и думаю, линковать статически или gcc собрать со старой libgcc

нет. статика тебе тут не поможет

тебе придётся и glibc линковать

и это тоже не поможет.

а если в итоговом бинаре окажется две статически слинкованных libstdc++/libc, можно словить больших проблем

почему?

ldd glibc.a там будет libnss как минимум

а зачем? Старая подходит по зависимостям пакету gcc-9

после статической линковки libstdc++/libc остаются только ld.so и какие-то ещё совершенно базовые либы, аби у которых меняется раз в 30 лет

оно будет работать только если списки функций и размеры типов совпадают. это + мильен UB

что за чушь?

ради эксперимента посмотрел зависимости одной из либ, которую линкую статически с stdc++: linux-gate.so.1 (0xf7f08000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7b27000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7b05000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7a01000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf79e2000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf77f9000) /lib/ld-linux.so.2 (0xf7f0a000) все эти либы не менялись уже много лет, не говоря уже о том, что у тс просто gcc-10 <-> gcc-9

Проблема только с libgcc_s... Версии остальных между gcc-8 -> 9 можно не менять вроде как

ну вот человек хочет юзать разные debian... вот он потом и расскажет) я уже проверял. если у тебя не пустой main() а есть например хотяб сокеты или даже dns то ты увидишь что списочек будет чуть больше.

libhidapi-hidraw.so.0 => /lib/x86_64-linux-gnu/libhidapi-hidraw.so.0 libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 Тут еще grpc+boost+qt статически влинкованы но список не слишком большой. Или я не так смотрю?

а каждая из этих либ никого больше не хочет?)

загуглил, но я не вижу её нигде в зависимостях. Эти хотят только друг друга

как только у тебя будет чтото типа dns (тыже не по ip собрался голому ходить) то ты получишь libnss. grpc просто транспорт же. короче оно не запустится просто. вот и всё

пока по айпи (что-то вроде огромной локалки), а там и bullseye перейдет в релиз и можно перекатываться.

проще просто dockerfile завести чтоб собрать бинарь для нужного дистра. без всякого гемора с линковкой

я бы завел, вот только мне надо чтобы потом завелось на бастере без докера, напрямую

докер нужен чтобы скомпилить в контейнере на нужный дистр.. дальше юзай просто файл где надо без докера

там как минимум boost::beast с http клиентом и сервером, думаю это уже показатель

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