Смешанная статическая и динамическая связь в Mac OS - PullRequest
3 голосов
/ 02 января 2011

Я хочу использовать gcc для создания разделяемой библиотеки, но я хочу связать некоторые другие библиотеки, от которых зависит статически.Теперь, чтобы создать «стандартный» динамически связанный выходной файл, я использую

gcc -dynamiclib *.o -lfoo -lbar -o outfile

, который будет

gcc -shared *.o -lfoo -lbar -o outfile

включен для binutils ld в системе linux.Теперь, если я хочу, чтобы libfoo и libbar были связаны статически, я могу назвать статические библиотеки напрямую

gcc -dynamiclib *.o /usr/lib/libfoo.a /usr/lib/libbar.a -o outfile

, однако, таким образом, я должен сам искать файлы библиотеки.GNU binutils ld поддерживает это:

gcc -shared *.o -l:libfoo.a -l:libbar.a -o outfile

но Apple ld не поддерживает.

  • Есть ли способ заставить ld Apple самостоятельно искать статические библиотеки?
  • Если нет, есть ли другой способ избежать точного определения местоположения архивов,например, создание промежуточного выходного файла из объектных файлов, требующих libfoo и libbar с переключателем -static, и связывание этого файла с оставшимися объектными файлами для создания динамического объекта?

Ответы [ 2 ]

8 голосов
/ 02 января 2011

Цитирование QA1393 ,

Обычно компоновщик проходит по каждому пути в путях поиска по одному, чтобы найти динамическую версию библиотеки.Если ничего не найдено, он проходит по каждому из этих путей в поисках статической версии той же библиотеки.Невозможно выбрать статическую библиотеку вместо соответствующей библиотеки, если обе библиотеки находятся в одном и том же каталоге, без использования опции компоновщика -l и абсолютных путей к каждой библиотеке.может поместить ваши статические библиотеки в другой каталог, использовать -L/path/to/static/libraries перед другими вхождениями -L, которые могут указывать на динамические библиотеки, и -search_paths_first, чтобы компоновщик пробовал и .dylib (которого не будет) и.a в первом пути поиска до поиска следующего пути поиска и т. д.

3 голосов
/ 07 апреля 2011

Я столкнулся с той же проблемой. Как выяснилось, похоже, что невозможно статически связать библиотеки без указания полного пути к .a-файлу.

Однако, кажется, изящный трюк в Makefile позволяет плавно использовать.

vpath %.a /opt/local/lib
.LIBPATTERNS lib%.a lib%.dylib lib%.so

STATICLIBS = -lssh2

libmy.dylib: my1.o my2.o $(STATICLIBS)
  g++ -dynamiclib -o libmy.dylib $^

Обратите внимание, как переменная $(STATICLIBS) вставлена ​​в зависимости. Make не будет обрабатывать зависимости с префиксом '-l' как файлы, а скорее как библиотеки. Используя вышеупомянутый vpath magic make, ищет библиотеки и указывает полный путь в командной строке к g ++.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...