Я просто посмотрел на это и подумал, что некоторые другие могут быть заинтересованы в моих выводах.
Слабая связь со слабым_импортом действительно работает только с динамическими библиотеками. Вы можете заставить его работать со статическими ссылками (указав -undefined dynamic_lookup, как предложено выше), но это не такая горячая идея. Это означает, что неопределенные символы не будут обнаружены до времени выполнения. Это то, чего я бы хотел избежать в рабочем коде, лично.
Вот сеанс терминала Mac OS X, показывающий, как заставить его работать:
Вот е.с
int f(int n)
{
return n * 7;
}
Вот что whatnof.c
#include <stdio.h>
#include <stdlib.h>
extern int f (int) __attribute__((weak_import));
int main() {
if(f == NULL)
printf("what, no f?\n");
else
printf("f(8) is %d\n", f(8));
exit(0);
}
Создать динамическую библиотеку из f.c:
$ cc -dynamiclib -o f.dylib f.c
Компилировать и связывать с динамической библиотекой, перечислять динамические библиотеки.
$ cc -o whatnof whatnof.c f.dylib
$ otool -L whatnof
whatnof:
f.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
Запустите Whatnof, чтобы увидеть, что происходит:
$ whatnof
f(8) is 56
Теперь замените f.dylib пустой библиотекой (без символов):
$ mv f.dylib f.dylib.real
$ touch null.c
$ cc -dynamiclib -o f.dylib null.c
Запустите то же самое, чтобы увидеть, что происходит:
$ whatnof
what, no f?
Основная идея (или «сценарий использования») для слабого_импорта заключается в том, что он позволяет связывать набор динамических (общих) библиотек, но затем запускать тот же код для более ранних версий тех же библиотек. Вы можете проверить функции по NULL, чтобы увидеть, поддерживаются ли они в конкретной динамической библиотеке, с которой в данный момент выполняется код. Это, кажется, является частью базовой модели разработки, поддерживаемой XCode. Я надеюсь, что этот пример полезен; это помогло мне успокоиться об этой части дизайна Xcode.