Подскажите пж что за бред со стороны cmake Мне нужно чтобы

из исходников собиралась статическая либа и все вызовы функций внутри нее были разрешены. Сама либа собирается. При попытке использовать ее в каком-то executable вылетают ошибки линковки: RenderSurface.cpp:45: undefined reference to `cm3d::Utility::GL::ShaderProgram::compile(...)
Этот символ находится в cm3dutil_gl и я линкую эту либу здесь. Когда я вместо этого линкую ее напрямую к конечному исполняемому файлу, ошибка пропадает. Т.е. последнюю строчку кода смак можно закомментировать и линковка выглядит абсолютно так же. PRIVATE/PUBLIC/INTERFACE в target_link_libraries никак не влияет на это дело. Можно как-то решить?

сам код для сборки либы:
set (fiercewild_SOURCES
Fiercewild.cpp
"Modules/RenderSurface.cpp"
"${CM3D_EXTERNAL_ROOT}/glad/src/gl.c"
)
add_library(fiercewild STATIC ${fiercewild_SOURCES})
add_dependencies(fiercewild cm3dutil_gl)
set_target_properties(fiercewild PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CM3D_RUNTIME_OUTPUT_DIR})
target_include_directories(fiercewild PRIVATE ${CM3D_INTERNAL_INCDIRS})
target_link_libraries(fiercewild PUBLIC ${CM3D_INTERNAL_GLFW_LIBS} "$<TARGET_FILE:cm3dutil_gl>")

собираю на линухе, clang 16

Там у тебя нет "attribbute((visibilty, <something>)) в коде?

нет, тупо хедеры с объявлениями и .cpp с определениями

Мне нужно чтобы из исходников собиралась статическая либа и все вызовы функций внутри нее были разрешены. Сама либа собирается Внутри стат либы символы не разрешаются

Проверь по логам cmake - а точно ли линкуется cm3d к твоей либе правильно, она же должна потом линковаться и к приложению.

Вы не можете линковать статик либу к статик либе. Обе либы нужно потом линковать к исполняемому файлу

Почему нет? Перепаковать файлы из двух архивов в один уже нельзя? Оо

нет, как раз уже проверил link.txt делает только ar -ql (или -qr) myobj1.o myobj2.o

никаких -l там нет

😐 понятно..

Ну это да. Но при линкове основной либы к запускаемому файлу или динамической либе - должны слинковаться все зависимости, все что было указано у либы в target_link_libraries PUBLIC

Но odr же можно получить и при линьковке двух статических либ в исполняемый файл, если в этих либах есть символы с одинаковым именем?

Каковы шансы получить 2 статических либы с одинаковыми символами, если одна либа включена в другую?

Шансы одинаковые, так как эта вероятность не зависит от порядка линьковки, а зависит только от самих либ. Если в двух статических либах оказались одинаковые символы, то ODR будет, как их не линькуй в exe ли сразу или переупаковав в одну и потом в exe. Если в двух либах нет одинаковых символов, то ODR не возникнет опять-же вне зависимости от способа линьковки.

Представьте что либу вам дал подрядчик/иной разработчик/откуда-то вообще возникла. Вы будете сильно удивлены, что в неё уже включена та же самая либа, которая используется у вас в проекте, но другой версии? Я бы удивился.

Еще раз, если это статические библиотеки, то опасность ODR не зависит от порядка сборки. Если это динамические библиотеки, то там есть видимость/экспорт и внутренние зависимости могут быть скрыты внутри и никак не проявить себя по ODR.

то есть линковать статик либы в статик либы можно и нужно? и это нормальная практика, и так делать хорошо? А то я пытаюсь объяснить почему это плохо, ибо вопрос изначально был про встраивание статик либы в статик либы, а вы говорите - "да не, всё норм, так и так можно накосячить"

Вы в качестве аргумента приводите риск, который не зависит от способа. Я вам пришу ровно об этом. Если уж хотите действительно объяснить, почему это плохо, то приводите реальные аргументы, что реально будет хуже. Про часть, которая в кавычках я даже говорить не хочу, ибо это исключительно ваша фантазия.