У меня есть несколько основных вопросов относительно связи с C/C++
библиотека. Я пытаюсь понять разницу в использовании двух разных способов использования -L/usr/local/lib -lm
использование и /usr/local/lib/libm.a
использование. Например, когда я собираю и связываю пример из [SUNDIALS]
библиотека, обе следующие работы
gcc -Wall cvRoberts_dns.c -o cvRoberts_dns.exe -I/usr/local/include -L/usr/local/lib/ -lsundials_cvode -lsundials_nvecserial -lm
ИЛИ ЖЕ
gcc -Wall cvRoberts_dns.c -o cvRoberts_dns.exe /usr/local/lib/libsundials_cvode.a /usr/local/lib/libsundials_nvecserial.a
Однако, чтобы скомпилировать и связать пример из библиотека [libsbml]
, следующие работы
g++ -Wall readSBML.cpp -o readSBML.exe -I/usr/local/include -L/usr/local/lib -lsbml
но это не
g++ -Wall readSBML.cpp -o readSBML.exe /usr/local/lib/libsbml.a
При необходимости я могу опубликовать полное сообщение об ошибке, но последняя строка сообщения выглядит следующим образом
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Мои вопросы следующие:
Во втором стиле ссылок (из первого примера) нет информации относительно того, где найти include
файлы (заголовочные файлы), как компилятор знает информацию, предоставленную в -I/usr/local/include
который предусмотрен в первом стиле первого примера?
Во втором стиле первого примера нет /usr/local/lib/libm.a
(на самом деле выдает сообщение об ошибке, libm.a
не могу найти, если я попытаюсь включить его), то почему -lm
требуется в первом стиле?
Как мне скомпилировать второй пример во втором стиле (т.е. используя /usr/local/lib/libsbml.a
)? Я вижу, что есть файлы — libsbml.a
а также libsbml-static.a
в /usr/local/lib
папка, но ни одна из них не работает.
Если это поможет, я нахожусь на OS X
машина.
Я был бы очень благодарен, если бы кто-нибудь мог помочь в этом отношении.
Просто обновление — я пробовал
g++ -Wall readSBML.cpp -o readSBML.exe /usr/local/lib/libsbml.5.dylib
и это скомпилировано и связано просто отлично.
Спасибо
SN
В общем
-L
Опция предназначена для поиска, где находятся сами библиотеки. Каждая библиотека представляет собой набор из одного или нескольких файлов объектного кода (машинного языка). Нет необходимости искать включаемые файлы.-I
Опция не имеет ничего общего с компоновщиком, она помогает компилятору разрешать файлы заголовков, используемые в вашей программе драйвера (например, Roberts_dns.c). Это происходит на этапе предварительной обработки.Во втором стиле связывания (из первого примера) нет
информация о том, где найти включаемые файлы (заголовочные файлы), ..
Если компиляция работала так, как вы ожидали, это может быть /usr/local/include
в пути по умолчанию для включения gcc
, Чтобы проверить путь включения по умолчанию для gcc
делать gcc -xc -E -v -
,
Во втором стиле первого примера нет
/usr/local/lib/libm.a(it фактически выдает сообщение об ошибке, что libm.a
не может быть найден, если я попытаюсь включить его), то почему -lm требуется в
первый стиль?
В Linux некоторые библиотеки, такие как libc.a
по умолчанию напрямую связаны с вашим исполняемым файлом libm.a
не является. В Mac (ваша среда), однако, libm — это прямая ссылка на исполняемый файл по умолчанию. Так что вам не нужно явно связывать это. Менее вероятно, что libm.a
находится в /usr/local/lib/
, Итак, вы получили ошибку. Но зачем связывать это в первую очередь?
Других решений пока нет …