Линковка статических библиотек .a

Происходит если функции из libcore.a пытаются обратится к функциям из libv.a и наоборот

Для статических недобиблиотек важен порядок линковки, попробуй другой:

target_link_libraries(example PUBLIC ${V} ${CORE})

В более сложных случаях (кольцевые зависимости) приходилось указывать библиотеки два раза два раза. Ещё посмотри https://stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause-errors-in-gcc или похожие вопросы, может там есть более правальные решения.

т.е. либы не видят эти заголовочные файлы

Это не имеет отношения к заголовочным файлам, иначе были бы ошибки компилятора а не линкера.

Вы правы, после того как поменяла местами, часть ‘undefined reference’ ушла. Остались проблемы в example.c.obj: In function `_main’ буквально со всеми функциями из этих библиотек.

А без всратого cmake, вы пробовали сделать?

Попыталась скомпилировать следующим образом: ''' gcc -o example example.c exmpl.h ''' Да, и на этом этапе возникают ошибки: undefined reference, ко всем тем функциям которые по идее описываются в exmpl.h. exmpl.h рядом с example.c, указан как #include «exmpl.h»

Логи где? И что выдает nm libv.a и nm libcore.a ?

Вы собираете бинарник программы с помощью статических либ. Вот когда надо было собирать статические либы — на этом этапе надо было бы предусмотреть, чтобы они друг о друге знали. Иначе они могут общаться не между собой, а только через вашу программу.

скомпилировать следующим образом: "' gcc -o example example.c exmpl.h "'

на месте компилятора, я бы тоже ругался :-)

вообще-то :

gcc -o example.o -c example.c

gcc -o example example.o libone.a libtwo.a

К сожалению не могу показать, библиотеки на самом деле не так называются. nm работает, выдает список всех объектных файлов в архивах библиотек.

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

сначала убедись, что это собирается вручную.

$ gcc example.c -lcore -lv ...

Если собирается, то открой Makefile, build.ninja, или что там у тебя cmake выдает, и посмотри как оно (не) собирается там.

Да, так собралось.

$ gcc -Wall -c example.c

$ gcc -o example example.o -L. -lcore -lv -lcore -lm -lpthread

Почему в таком виде не надо указывать заголовочный файл?

Попыталась сделать такую же последовательность в cmake - не срабатывает:

add_executable(example example.c exmpl.h)

target_link_libraries(example PUBLIC ${CORE} ${V} ${CORE} m pthread)

Почему в таком виде не надо указывать заголовочный файл?

Заголовочный файл при линковке не нужен.

Заголовочный файл это просто кусок кода на Си, который подставляется в компилируемый исходник.

Допустим, у тебя в заголовочном файле написано extern void foo(int a);. Компилятор запоминает, что foo — это функция, которая находится где-то снаружи, и идёт дальше.

Когда компилятор создаёт объектный файл, у тебя там в машинном коде будет, например, вызов к внешней функции foo. Теперь задача линковщика – соединить объектные файлы. Если на этапе линковки не будет найдено, откуда взять foo, то будет ошибка линковки.

Почему в таком виде не надо указывать заголовочный файл?

И еще в дополнение к этому. Передавать заголовочные файлы параметрами компилятору – не надо.

У тебя в файле .c есть строки вида #include "что-то.h".

Когда компилятор видит такую строку, он ищет указанный заголовочный файл и просто подставляет его содержимое вместо строки.

Если заголовочные файлы лежат в нестандартном месте, то компилятору передаётся ключ вида -Iпуть, чтобы он знал, в каких каталогах искать.

Я к тому, что они могут быть не слинкованы друг с другом, и так, как вы объясняете, работать не будет.

Да, так собралось.
$ gcc -Wall -c example.c
$ gcc -o example example.o -L. -lcore -lv -lcore -lm -lpthread

Подозреваю, что все дело во флаге -L. который подсказал линкеру искать библиотеки в текущем каталоге кроме стандартных путей. Как компилятору надо подсказывать, где лежат h-файлы (флаг -I), так и линкеру надо указывать путь до нестандартных библиотек (флаг -L).

Надо смотреть какую команду для линкера сгенерировал CMake, тогда будет ясно почему он не может найти функции внутри стат.библиотек. Сделай

cmake ../
make VERBOSE=1

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

Я наконец-то смогла локализовать проблему: когда я пытаюсь собрать программу через cmake, вылезают ошибки типа "undefined reference to ‘_core_Malloc’, но просмотрев либу через nm libcore.a, обнаружила, что там все названия без нижнего подчеркивания ‘core_Malloc’ и т.д.

Вроде бы так отражаются различия между С/С++, т.е. моя программа и CMakeLists написаны под С, либы собраны под С++. Видимо, когда я собираю вручную, компилятор это понимает и ищет и с подчеркиванием и без (какая-то опция компиляции?).

Можно ли как то учесть это через CMakeLists?

но просмотрев либу через nm libcore.a, обнаружила, что там все названия без нижнего подчеркивания ‘core_Malloc’

У тебя есть либы сторонние на Си, есть твоя С++ софтина их юзающая. Верно? Попробуй:

extern "C" {
#include <your_external_c_library.h>
}

Возможно автор не учел возможность компиляции плюсовым компилятором

Как ни парадоксально, но наоборот: программа на Си, либы предположительно на С++. Попробовала использовать extern «C++» { #include exmpl.h }, но в таком виде ругается: error: expected identifier or ‘(’: extern «C++» {… Видимо в Си подключение выглядит другим образом. Есть ли оно вообще ?

хотя я нашла, что внутри заголовочного файла этой либы всё обернуто следующей конструкцией:

#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif

Тогда все должно быть норм с именами. Даже не знаю чего тебе сказать