2011-03-10 3 views
0

[отредактировано] Я отредактировал вопрос, чтобы изолировать проблему и помочь другим людям лучше.dyld: Symbol not found problem (NSMutableAttributedString, похоже, сильно связан)


Я использую NSMutableAttributedString класс в мое приложение, которое доступно в прошивкой 3.2 и более поздних версий. Однако я также нацелен на устройства с версией 3.1.2; для обратной совместимости, я использовал следующий код:

CFAttributedStringRef attributedString; 
if (NSClassFromString(@"NSMutableAttributedString")) { 
    attributedString = (CFAttributedStringRef)[[[NSMutableAttributedString alloc] 
      /* init... to initialize an object */ ] autorelease]; 
} else { 
    attributedString = CFAttributedStringCreate(kCFAllocatorDefault, 
      (CFStringRef)NSLocalizedString(@"MessageInEllipse", 
      @"Message to show in an ellipse"), 
      (CFDictionaryRef)attributes); 
    } 
} 

В строке 3, я непосредственно использовать имя класса NSMutableAttributedString, но я ожидал, что это будет слабо линковкой, так это просто означает, nil здесь и приложение будет работать без проблем.

Однако при запуске приложения на устройствах 3.1.2 оно запускается, жалуясь, что не может найти символ NSMutableAttributedString. Кажется, что этот символ класса сильно связан. Почему это произойдет?

ответ

0

Слабая связь с определенным классом не доступна во всех случаях. Чтобы слабо соединить символ класса,

  • Базовый SDK должен быть iOS 4.2 или новее.
  • Цель развертывания должна быть iOS 3.1 или новее.
  • Компилятор должен быть LLVM-GCC 4.2 или новее, или LLVM-Clang 1.5 или новее.
  • Класс, к которому вы хотите подключиться слабо, должен быть объявлен с использованием макроса NS_CLASS_AVAILABLE.
  • Структура, к которой принадлежит класс, должна существовать в версии для развертывания, а если в противном случае сама структура должна быть слабо связана.

Третье условие было моей проблемой, потому что я неправомерно думал, что использую LLVM (я нашел это только с помощью форума Apple). GCC - это стандартное значение Xcode 3, поэтому вы должны быть осторожны.

Если эти условия не сохранены, вы не можете использовать слабую связь. В этом случае, вместо того, чтобы использовать [NSMutableAttributedString alloc], например, я должен сделать как [NSClassFromString(@"NSMutableAttributedString") alloc].

Остается упомянуть одно. Как и в ответе @ sza, если я слабо свяжусь с самой картой (Foundation в этом случае), я могу использовать слабую связь с отсутствующим классом даже с GCC 4.2. Хотя это может решить проблему сразу, на мой взгляд, похоже на практику, которой следует избегать. Я осторожен в этом, потому что я не уверен, насколько слабая связь с каркасом работает во время выполнения, но не будет ли это налагать больше накладных расходов на производительность, чем сильная связь с каркасом, потому что необходимо получить всю информацию о структуре во время выполнения? Поэтому, если я слабо свяжусь с фреймворком, который часто используется (конечно, Foundation), я думаю, у меня может быть проблема с производительностью. По крайней мере, ссылки очень специфичны, чтобы сказать, что они слабо связаны с каркасом , если эта структура недоступна для некоторых целей развертывания.

Поэтому, я думаю, что лучшая практика здесь:

  • всегда сильно связывают с каркасами, которые доступны в моей цели развертывания

и если я использую класс рамок, становится доступным после цели развертывания

  1. использовать слабое связывание, если я могу отвечать требованиям, ИЛИ
  2. всегда используют NSClassFromString() для обозначения класса, независимо от того, что не будет выполнен или не в старых версиях IOS.
0

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

+0

На самом деле, я считаю, что нецелесообразно полагаться на слабое соединение с фреймами (чтобы слабо связать символ класса), когда сама инфраструктура доступна для цели развертывания, и только класс отсутствует. Я отправил ответ, чтобы описать, что я нашел в эти дни. Однако вы направили меня в правильном направлении, и я ценю это! – MHC

Смежные вопросы