Side-by-side GLIBC

да, собирал в контейнерах

Да, но это лишний треш и геморрой. Лучше собирай с musl тогда, в нём хотя бы статическая линковка поддерживается.

А вообще, для этого контейнеры и существуют.

Если не нужен общесистемный nsswitch, то проще собрать с musl.

Если нужен - то всё равно придётся собирать с системной glibc.

Собирай кросскомпилятором ZIG

Используй zig cc, там можно явно задавать какую угодно версию жлибц.

Либо да, собирать статически с мюслем (тоже с помощью zig cc)

crossdev

ну либо выше посоветовали zig, но crossdev универсальней и более гибкий

Опыт создания симлинков с новых глибц на системые для любителей свежака показывает, что больше чем в половине случаев в новой глибц нет необходимости.

Зачем тебе новое glibc? Там ничего существенного последние 15 лет не менялось.

в chroot собирай без всяких контейнеров

Собираешь, что-бы ты под этим не понимал. Зачем компилировать? Просто другого слова не знаешь?

Для примера.

Я последние 15 лет продаю ПО, которое сам и собираю.

Сейчас мы перестали поддерживать убунту 16 и вроде бы даже не обещаем работу на 18-й.

Разница в libc между 18-й убунтой и 26-й для высокопроизводительного стримингового сервера незначительная. Если бы не загоны с версиями функций, то работали бы и на 10-й.

Если тот, кто запускает твой софт, настолько упертый баран, что держится за ОС 10-летней давности, то твоя работа не оплатится и вредна. Если ты заложился на какую-то самую супер-свежую функцию в libc, то возможно ты опрометчиво поступил.

Короче, проблемы особо не должно быть. Просто собирай в докере под чем-то типа 20-й или 22-й.

Вроде ж тупо передаёшь gcc-линкеру опцию -static, и он генерирует статический бинарник вообще без внешних символов.

С glibc есть нюансы, тут -static не поможет

Там ничего существенного последние 15 лет не менялось.

Спорное утверждение, но согласен что гонять свежий libc на старом ядре - удовольствие довольно сомнительное, и лучше сборку libc отдать на откуп дистростроителям.

Лучше proot использовать. Падений производительности нету и можно с qemu использовать

С glibc есть нюансы, тут -static не поможет

Что за нюансы? Лично мне прекрасненько помогало. Например, делал докер-образ из одного единственного статически слинкованного бинарника.

Лучше proot использовать. Падений производительности нету

Вы же знаете что proot это чуть ли не единственная система контейнеризации где на каждый системный вызов выполняется дополнеительный userspce-код, который в отличии от chroot и docker имеет шансы проблем производительности?

можно с qemu использовать

Вы же знаете что qemu-user-static прекрасно интегрируется c chroot и прозрачно интегрируется с docker, в обоих случах позволяя запускать окружение в котром всё начиная c / ненативной архитектуры и единственный нативный файл это /bin/qemu-user-static-архитектура который послужил точкой входа. В таком не-нативном оуркжении стабильно работают компиляторы и даже графичкские X11-приложения (QtCreator). Единственное что не работает в таком qemu-user - системный вызов ptrace, то есть отладчики и упомянутый proot. То есть с qemu-user как раз таки только proot использовать нельзя