горе компоновщика - неопределенная ссылка

Я боюсь, что Вы смешали понятия заголовка и библиотека. Скажем, у Вас есть библиотека libmylib.a это содержит функцию myfunc() и соответствующий заголовок mylib.h это определяет его прототип. В Вашем исходном файле myapp.c Вы включаете заголовок, или непосредственно или включая другой заголовок, который включает его. Например:

/* myapp.h
** Here I will include and define my stuff
*/
...
#include "mylib.h"
...

Ваш исходный файл похож:

/* myapp.c
** Here is my real code
*/
...
#include "myapp.h"
...
/* Here I can use the function */
myfunc(3,"XYZ");

Теперь можно скомпилировать его для получения myapp.o:

gcc -c -I../mylib/includes myapp.c

Обратите внимание, что-I просто говорит gcc, где файлы заголовков, они не имеют никакого отношения к самой библиотеке!

Теперь можно связать приложение с реальной библиотекой:

gcc -o myapp -L../mylib/libs myapp.o -lmylib

Обратите внимание что -L переключатель говорит gcc, где библиотека, и -l говорит этому связывать Ваш код с библиотекой.

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

Могли бы быть другие более сложные случаи, но от Вашего вопроса, я надеюсь, что этого было бы достаточно для решения проблемы.

Заголовки предоставляют объявления функции и функциональные определения. Чтобы позволить компоновщику находят реализацию функции (и избавьтесь от неопределенной ссылки), необходимо попросить, чтобы драйвер компилятора (gcc) связал определенную библиотеку, где функция находится с помощью флага-l. Например,-lm свяжет математическую библиотеку. Страница руководства функции обычно указывает то, что библиотека, если таковые имеются, должна быть указана для нахождения функции.

Если компоновщик не может найти указанную библиотеку, можно добавить путь поиска библиотеки с помощью переключателя-L (например,-L/usr/local/lib). Можно также постоянно влиять на путь к библиотеке через переменную среды LIBRARY_PATH.

Вот некоторые дополнительные детали, чтобы помочь Вам отладить свою проблему. Условно названия файлов библиотеки снабжаются префиксом lib, и (в их статической форме) имеют.a расширение. Таким образом статически связанная версия математической библиотеки системы по умолчанию (тот Вы связываетесь с-lm) обычно находится в/usr/lib/libm.a. Видеть, какие символы данная библиотека определяют Вас, может выполнить nm - только определенный на файле библиотеки. В моей системе, выполняя команду на libm.a дает мне вывод как следующее.

e_atan2.o:
00000000 T atan2

e_asinf.o:
00000000 T asinf

e_asin.o:
00000000 T asin

Для наблюдения пути к библиотеке, который использует компилятор и какие библиотеки он загружает по умолчанию, можно вызвать gcc с-v опцией. Снова в моей системе это дает следующий вывод.

GNU assembler version 2.15 [FreeBSD] 2004-05-23 (i386-obrien-freebsd) 
using BFD version 2.15 [FreeBSD] 2004-05-23
/usr/bin/ld -V -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o 
/usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /var/tmp//ccIxJczl.o -lgcc -lc 
-lgcc /usr/lib/crtend.o /usr/lib/crtn.o

Отправьте свой make-файл и библиотечную функцию, которую Вы пытаетесь назвать. Даже простые gcc make-файлы обычно имеют строку как это:

LIBFLAGS =-lc -lpthread -lrt -lstdc++ -lShared -L../shared

В этом случае это означает, связывают стандартную библиотеку для C, среди других

Я предполагаю, что необходимо добавить путь, где компоновщик может найти библиотеку. В gcc/ld можно сделать это с-L и библиотеку с-l.

- Ldir, - library-path=dir

Поисковый dir каталога перед стандартными поисковыми каталогами (эта опция должна предшествовать-l опции, которая ищет тот каталог).

- лиственница, - library=archive

Включайте дугу архивного файла в список файлов для соединения.

Ответ на ответы - нет никакого.a файла библиотеки, просто.h и.c в библиотеке, таким образом-l не является approriate

Затем Вам, вероятно, придется создать библиотеку сначала?

gcc -c mylib.c -o mylib.o
ar  rcs libmylib.a      mylib.o