Статические бинарники и кросс-компиляция: CGO_ENABLED=0, загадка пропавшего ld-linux и дисциплина флагов сборки

Развилка в каждой сборке: CGO_ENABLED

$ CGO_ENABLED=1 go build -o server-cgo .     # дефолт при нативной сборке с C-тулчейном
$ CGO_ENABLED=0 go build -o server-static .  # чистый Go, никакого C

$ file server-cgo
server-cgo: ELF 64-bit LSB executable, dynamically linked,
            interpreter /lib64/ld-linux-x86-64.so.2 ...
$ file server-static
server-static: ELF 64-bit LSB executable, statically linked ...

$ ldd server-cgo
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

Зачем языку с собственным рантаймом вообще линковать libc? Два пакета stdlib уходят в C, когда cgo доступен: net (резолв имён через getaddrinfo) и os/user (поиск аккаунтов). При CGO_ENABLED=1 — дефолте всякой нативной сборки при наличии C-компилятора — эти пути компилируются внутрь, и линковщик записывает в ELF-заголовок (ELF, Executable and Linkable Format — стандартный формат исполняемых файлов в Linux) динамический интерпретатор. Это и есть вся анатомия загадки из крючка: execve открывает бинарник, читает PT_INTERP (секцию ELF-заголовка с путём к динамическому загрузчику) и пытается загрузить /lib64/ld-linux-x86-64.so.2 — файл, которого в scratch нет. Возвращённый ENOENT называет бинарник, который вы запускали, а не интерпретатор, которого не нашлось, — поэтому ошибка читается как ложь. Вариант с Alpine — тот же баг в другой краске: glibc-собранный бинарник просит glibc-загрузчик, а musl кладёт /lib/ld-musl-x86_64.so.1.

Подмена резолвера — более тонкая половина. С вкомпилированным cgo Go решает на каждый лукап, звать getaddrinfo или собственный DNS-клиент, — по содержимому /etc/nsswitch.conf и /etc/resolv.conf плюс пара переменных окружения; всё, что Go не умеет эмулировать (модули mdns или nis, экзотические опции resolv), уходит через libc. CGO_ENABLED=0 убирает сам выбор: всегда чистый резолвер, который читает /etc/hosts и /etc/resolv.conf и сам говорит по DNS. В scratch нет nsswitch.conf вовсе, и Go-резолвер принимает стандартный порядок «files, потом dns» — всё хорошо, пока инфраструктура молча не зависела от плагина nsswitch: hosts из LDAP, mDNS, кэш nscd исчезают без единого сообщения об ошибке. Когда подозревается само решение, GODEBUG=netdns=go+1 форсирует чистый резолвер и логирует выбор; netdns=cgo+1 форсирует другую ветку.

Когда cgo не выкинуть — и матрица кросс-компиляции

Честный список исключений короток. mattn/go-sqlite3 оборачивает C-библиотеку — modernc.org/sqlite даёт чистый Go-выход, но с реальной (мерьте сами, часто 1,5-2x) ценой по скорости. Детектор гонок построен на C++-рантайме ThreadSanitizer, так что сборки с -race требуют cgo — и это нормально: это артефакт CI и тестов, никогда не релизный бинарник. Некоторым корпоративным DNS-окружениям действительно нужны модули nsswitch — то есть cgo-резолвер. И пакет plugin. Рабочий паттерн: cgo там, где реально живёт C-зависимость, CGO_ENABLED=0 — для артефакта деплоя.

Кросс-компиляция — место, где Go собирает дивиденды за всё это:

$ GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -o server-arm64 ./cmd/server
$ go tool dist list | wc -l   # поддерживаемая матрица GOOS/GOARCH
      44

Две переменные окружения с любой машины разработчика — ноутбук на Mac выпускает Linux-ARM-бинарники без единой дополнительной установки, потому что тулчейн Go несёт кодогенерацию под каждую цель, а чистый рантайм делает сисколы сам, без целевого libc, который надо где-то взять. Сравните с миром C: кросс-тулчейн, sysroot и система сборки, уважающая и то и другое, — на каждую цель. Как только входит cgo, вы наследуете ровно этот зоопарк: кросс-сборка cgo-кода требует настоящего C-кросс-компилятора (CC=aarch64-linux-gnu-gcc или современный трюк с zig cc) и каждой транзитивно линкуемой C-библиотеки, собранной под цель.

Дисциплина флагов и происхождение

Когда вы выпускаете бинарник, вы неявно делаете три заявления: этот код пришёл из этого коммита, это версия, которую прочитает дежурный в алерте, и этот образ идентичен тому, что проверял CI. Ни одно из них не истинно по умолчанию — для каждого нужен конкретный флаг или команда аудита.

$ go build -trimpath \
    -ldflags="-s -w -X main.version=v1.42.0" \
    -o server ./cmd/server

$ go version -m server
server: go1.25.4
        path    example.com/api/cmd/server
        mod     example.com/api v1.42.0
        dep     github.com/jackc/pgx/v5 v5.7.1 h1:...
        build   -trimpath=true
        build   CGO_ENABLED=0
        build   vcs.revision=9f3c2e1a...
        build   vcs.modified=false

-trimpath вычищает из бинарника пути сборочной машины, и одинаковые исходники с одинаковым тулчейном дают бит-в-бит идентичный артефакт на любой машине — предусловие воспроизводимых сборок и доверия к тому, что бинарник соответствует коммиту. -ldflags="-s -w" выбрасывает ELF-таблицу символов и DWARF, обычно минус 25-30% размера (сервис на 9 МБ приземляется около 6,5 МБ). Честная бухгалтерия: стектрейсы паник по-прежнему символизируются — рантайм держит собственный pclntab (таблица соответствия адресов программного счётчика именам функций и номерам строк); теряете вы DWARF, то есть delve на прод-бинарнике, gdb и внешние инструменты символизации. Сеньорский ход — перестать считать это трейдоффом: собирайте на деплой со стрипом и архивируйте нестрипнутого близнеца (или заливайте символы в трекер ошибок) — получаете и маленький образ, и отлаживаемый артефакт. -X importpath.var=value внедряет человеческую версию в строковую переменную на этапе линковки; с Go 1.18 тулчейн сам встраивает vcs.revision, vcs.time и vcs.modified, так что коммит записан, даже если -X никто не передавал.

Суперсила аудита — последняя строка: go version -m работает на любом Go-бинарнике, включая скопированный из прод-контейнера, и печатает модуль, полный список зависимостей с хэшами и настройки сборки. Вопрос «что именно сейчас крутится» в три часа ночи перестаёт быть археологией и становится одной командой.