Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

CMake target_link_libraries

Почему это важно для SCA/OSA

target_link_libraries — это место, где в CMake-проекте фиксируется факт линковки, но почти никогда не фиксируется версия и источник библиотеки. Команда target_link_libraries(app PRIVATE ssl crypto z) говорит линковщику «подключи -lssl -lcrypto -lz», а откуда возьмутся эти .so — решает уже поисковый путь линковщика на конкретной сборочной машине. Для SCA это значит, что текст CMakeLists.txt сам по себе не отвечает на главный вопрос композиционного анализа: какая именно версия OpenSSL и zlib попала в артефакт. Имя в target_link_libraries — это evidence-«identity по имени», но не координата компонента.

Вторая причина — ключевые слова видимости PRIVATE / PUBLIC / INTERFACE. Они управляют тем, протекает ли зависимость дальше по графу к потребителям таргета. Неверно поставленная видимость либо прячет реальную транзитивную зависимость от анализа, либо, наоборот, раздувает граф фантомными связями, которых нет в бинаре.

Как это проявляется

Сравните две формы записи — для SCA это разные миры:

Запись Что несёт Видно ли версию
target_link_libraries(app PRIVATE ssl z) сырые флаги -lssl -lz, резолв по find_library/пути линковщика нет
target_link_libraries(app PRIVATE OpenSSL::SSL ZLIB::ZLIB) imported targets от find_package(OpenSSL) косвенно, через OpenSSL_VERSION

Стандартный приём «снять граф CMake» вскрывает ровно ту самую слепую зону:

Граф CMake показывает таргеты, а не .so

cmake -S . -B build
cmake --build build --target app -- VERBOSE=1   # увидеть реальную команду линковки
cmake --graphviz=deps.dot build                  # граф CMake-таргетов

deps.dot нарисует связи между CMake-таргетами (app -> OpenSSL::SSL), но он не знает, что OpenSSL::SSL на этой машине разрешился в /usr/lib/x86_64-linux-gnu/libssl.so.3 из пакета libssl3. Эту последнюю связь даёт только ldd build/app плюс dpkg -S, а не граф CMake.

Слепая зона или приём

Граф CMake обрывается на границе imported target. Если зависимость подключена «сырым» именем (ssl, z), CMake вообще не считает её узлом графа — это просто строка флагов, которую увидит только разбор команды линковки (VERBOSE=1) или ldd готового бинаря. Поэтому опираться на cmake --graphviz как на источник состава нельзя: он отражает намерение разработчика, а не разрешённые версии.

Перехват вызовов компилятора надёжнее графа Сгенерируйте compile_commands.json (-DCMAKE_EXPORT_COMPILE_COMMANDS=ON) и снимите реальные команды сборки через build-scan-обёртку. Так фиксируются фактические -l, -L, -I и абсолютные пути к .a/.so, а не декларации из CMakeLists.txt.

Что делать на проекте

  1. Соберите проект с VERBOSE=1 и сохраните команду линковки таргета — это первичное evidence по линковке.
  2. Включите -DCMAKE_EXPORT_COMPILE_COMMANDS=ON, заберите compile_commands.json как артефакт сборки.
  3. Снимите cmake --graphviz=deps.dot — но трактуйте его как карту намерений, а не как состав.
  4. Для каждого imported target (Foo::Bar) найдите, из какого find_package/.cmake-модуля он пришёл и какую версию подтянул (message(STATUS "${OPENSSL_VERSION}")).
  5. Прогоните ldd по готовому артефакту и смаппьте .so на DEB/RPM-пакеты — это закрывает разрыв между CMake-таргетом и реальной библиотекой.
  6. Отдельно отметьте «сырые» имена в target_link_libraries (без ::) — по ним версия не доказана, запись идёт в worklist доразметки.

Связь