Изменение символа Leopard в OSX 10.5 с помощью $non_lazy_ptr

От: Подключение разработчика — непрямая адресация

Косвенная адресация — это название метода генерации кода, который позволяет ссылаться на символы, определенные в одном файле, из другого файла, не требуя, чтобы ссылающийся файл имел явное знание макета файла, который определяет символ. Следовательно, определяющий файл может быть изменен независимо от исходного файла. Косвенная адресация сводит к минимуму количество местоположений, которые должны быть изменены динамическим компоновщиком, что облегчает совместное использование кода и повышает производительность.

Когда файл использует данные, определенные в другом файле, он создает ссылки на символы. Ссылка на символ идентифицирует файл, из которого импортируется символ, и символ, на который указывает ссылка. Существует два типа ссылок на символы: неленивые и ленивые.

Неленивые ссылки на символы разрешаются (привязываются к их определениям) динамическим компоновщиком при загрузке модуля. Неленивая ссылка на символ — это, по сути, указатель на символ — фрагмент данных размером с указатель. Компилятор генерирует неленивые ссылки на символы для символов данных или адресов функций.

Ленивые ссылки на символы разрешаются динамическим компоновщиком при первом использовании (не во время загрузки). Последующие обращения к указанному символу переходят непосредственно к определению символа. Ленивые ссылки на символы состоят из указателя символа и заглушки символа, небольшого количества кода, который напрямую разыменовывает и перескакивает через указатель символа. Компилятор генерирует ленивые ссылки на символы, когда встречает вызов функции, определенной в другом файле.

Говоря человеческим языком: компилятор генерирует заглушки с добавленным к ним $non_lazy_ptr для ускорения компоновки. Вы, вероятно, заметили, что функция Foo, на которую ссылается _Foo$non_lazy_ptr, не определена или что-то в этом роде — это не одно и то же. Убедитесь, что символ действительно объявлен и экспортирован в объектные файлы/библиотеки, с которыми вы связываете свое приложение. По крайней мере, это была моя проблема, я также думал, что это странная штука с компоновщиком, пока не обнаружил, что моя проблема была в другом - есть несколько других возможных причин, найденных в Google.

ranlib -c libwhatever.a

является надежным решением проблемы. У меня была такая же проблема при создании библиотеки PJSIP для iOS. Эта библиотека как бы использует систему make на основе autoconf, но требует небольшой настройки различных файлов, чтобы все было в порядке для iOS. В процессе этого мне удалось удалить строку ranlib в правиле для библиотек, а затем я начал получать ошибку в ссылке моего проекта о том, что _PJ_NO_MEMORY_EXCEPTION ссылается на _PJ_NO_MEMORY_EXCEPTION$non_lazy_ptr, будучи неопределенным.

Добавление строки ranlib обратно в файл библиотеки решило эту проблему. Теперь моя полная запись для LIBS в rules.mak

$(LIB): $(OBJDIRS) $(OBJS) $($(APP)_EXTRA_DEP)
    if test ! -d $(LIBDIR); then $(subst @@,$(subst /,$(HOST_PSEP),$(LIBDIR)),$(HOST_MKDIR)); fi
    $(LIBTOOL) -o $(LIB) $(OBJS)
    $(RANLIB) -c $(LIB)

Надеюсь, это поможет и другим, пытающимся использовать общие внешние библиотеки, настроенные для UNIX, с iPhone или iOS.

Если кто-то еще столкнется с той же проблемой, что и у меня:

Был extern NSString* const someString; в заголовочном файле, но забыл поставить его в файле реализации. как NSString* const someString=@"someString";

Это решило это.

ranlib -c в вашем файле библиотеки устраняет проблему