П19. C/C++ make build inventory

Цель

По многословному (verbose) логу сборки make восстановить, какие библиотеки реально передаются линкеру (флаги -l и -L), и сравнить этот список с тем, что подсказывают #include в исходниках. Проверяемый результат: текстовый файл со списком линкуемых библиотек, где для каждой явно отмечено, динамическая она (-lssl) или статическая (-l:libssl.a, -static).

Команда или действие

Перехватываем команды линковки из verbose-сборки. У GNU Make флаг — V=1 или цель, печатающая команды (make сам не скрывает их, скрывает обычно сгенерированный Makefile через @):

# 1. чистая пересборка с печатью реальных команд компилятора и линкера
make clean
make V=1 2>&1 | tee build.log     # для autotools-проектов; в CMake-Makefile: make VERBOSE=1

# 2. вытащить из лога строки линковки и показать только -l / -L / -static
grep -E '\-l|\-L|\-static' build.log | grep -E 'gcc|g\+\+|c\+\+|ld' > link-lines.txt

# 3. отдельно выписать имена библиотек
grep -oE '\-l[:]?[A-Za-z0-9._+-]+' build.log | sort -u > linked-libs.txt

Почему именно verbose-лог, а не readelf готового бинаря readelf -d (см. П22. ELF dynamic dependencies) покажет только то, что осталось в динамической секции. Флаг -l:libfoo.a или -Wl,-Bstatic в логе линковки — единственное место, где статически вшитая библиотека ещё видна по имени. Поздний скан бинаря её уже не вернёт.

Что вы должны увидеть

В build.log — реальные вызовы линкера, например:

g++ -o app main.o net.o -L/usr/lib/x86_64-linux-gnu -lssl -lcrypto -lz -l:libcustom.a

В linked-libs.txt — короткий нормализованный список (для среднего тестового проекта обычно 3–8 строк):

-l:libcustom.a
-lcrypto
-lssl
-lz

Ориентир по результату: количество строк -l в логе должно быть больше или равно числу уникальных #include сторонних заголовков. Если библиотек по -l заметно меньше, чем заголовков, — часть зависимостей либо header-only, либо вшита статически без отдельного -l (через объектные файлы), и это уже зацепка для П23. Статическая линковка как слепая зона.

Если не получилось

• Лог пустой или команды скрыты @. Многие сгенерированные Makefile (CMake, KBuild) глушат вывод. Для CMake-сборки используйте make VERBOSE=1, для autotools — make V=1; если не помогло, пересоберите через make SHELL='sh -x' или подключите перехватчик (bear -- make, compiledb make).
• make: Nothing to be done for 'all'. Сборка инкрементальная и линковка не выполнялась повторно. Обязательно сделайте make clean (или соберите в чистом дереве) — иначе строки линковки в лог не попадут.
• В логе видны только -I (include), но нет -l. Вы поймали стадию компиляции, но не линковки. Проверьте, что сборка дошла до конца и создала исполняемый файл; ищите строку с -o <имя_бинаря>.
• Библиотека приходит через pkg-config. В логе будет развёрнутый набор флагов из $(pkg-config --libs ...); имя пакета pkg-config (например openssl) не всегда совпадает с именем .so — это нормально, сверяйте по -l, а не по имени модуля pkg-config.

Критерий зачёта

Показать преподавателю: build.log, полученный из чистой пересборки; linked-libs.txt; и устную (или письменную) разметку каждой библиотеки на «динамическая / статическая / header-only», подкреплённую конкретной строкой из лога. Зачёт не ставится, если список собран из #include, а не из реальных команд линковки.

Нормативная связка

Build-scan по логу сборки — это управляемость работ по ГОСТ Р 56939-2024 и практики PS.3.2 / PW.4 из NIST SP 800-218 SSDF: состав ПО фиксируется на этапе сборки, а не реконструируется задним числом. Полнота перечня компонентов — критерий качества SBOM по BSI TR-03183-2 v2.1.0. Смежные практики модуля М09: П20. CMake dependency graph, П22. ELF dynamic dependencies, П23. Статическая линковка как слепая зона. Шаблон: Реестр unresolved libraries.