солнечные часы — связывание с библиотекой c / c ++

У меня есть несколько основных вопросов относительно связи с 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)

Мои вопросы следующие:

  1. Во втором стиле ссылок (из первого примера) нет информации относительно того, где найти include файлы (заголовочные файлы), как компилятор знает информацию, предоставленную в -I/usr/local/include который предусмотрен в первом стиле первого примера?

  2. Во втором стиле первого примера нет /usr/local/lib/libm.a (на самом деле выдает сообщение об ошибке, libm.a не могу найти, если я попытаюсь включить его), то почему -lm требуется в первом стиле?

  3. Как мне скомпилировать второй пример во втором стиле (т.е. используя /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

2

Решение

В общем

  • -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/, Итак, вы получили ошибку. Но зачем связывать это в первую очередь?

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]