Pourquoi Leopard altère-t-il certains symboles avec $ non_lazy_ptr? Plus important encore, quelle est la meilleure méthode pour corriger les erreurs de symboles indéfinies parce qu'un symbole a été modifié avec $ non_lazy_ptr?
De: Developer Connection - Indirect Addressing
adressage indirect est le nom de la technique de génération de code qui permet aux symboles définis dans un fichier à être référencés à partir d'un autre fichier, sans que le fichier de référencement pour avoir une connaissance explicite de la mise en page du fichier cela définit le symbole. Par conséquent, le fichier de définition peut être modifié indépendamment du fichier de référence. L'adressage indirect minimise le nombre d'emplacements devant être modifiés par l'éditeur de liens dynamiques, ce qui facilite le partage de code et améliore les performances.
Lorsqu'un fichier utilise des données définies dans un autre fichier, il crée des références de symbole. Une référence de symbole identifie le fichier à partir duquel un symbole est importé et le symbole référencé. Il existe deux types de références de symboles: nonlazy et paresseux.
Les références de symboles non lustrées sont résolues (liées à leurs définitions) par l'éditeur de liens dynamiques lorsqu'un module est chargé. Une référence de symbole non lustrée est essentiellement un pointeur de symbole - un élément de données de la taille d'un pointeur. Le compilateur génère des références de symboles non lustrées pour les symboles de données ou les adresses de fonctions.
Les références de symboles paresseux sont résolues par le lieur dynamique la première fois qu'elles sont utilisées (pas au moment du chargement). Les appels suivants au symbole référencé sautent directement à la définition du symbole. Les références de symboles paresseux sont constituées d'un pointeur de symbole et d'un bout de symbole, d'une petite quantité de code qui déréférence directe et saute à travers le pointeur de symbole. Le compilateur génère des références de symboles paresseux lorsqu'il rencontre un appel à une fonction définie dans un autre fichier.
En langage humain: le compilateur génère des stubs avec $ non_lazy_ptr ajouté pour accélérer la liaison. Vous voyez probablement que la fonction Foo référencée par _Foo $ non_lazy_ptr n'est pas définie, ou quelque chose comme ça - ce ne sont pas la même chose. Assurez-vous que le symbole est effectivement déclaré et exporté dans les fichiers/bibliothèques d'objets auxquels vous liez votre application. Au moins, c'était mon problème, je pensais aussi que c'était un lien bizarre jusqu'à ce que je trouve que mon problème était ailleurs - il y a plusieurs autres causes possibles trouvées sur Google.
ranlib -c sur votre fichier de bibliothèque résout le problème
Si quelqu'un trébuche autre le même problème que moi:
Had a extern NSString* const someString; dans le fichier d'en-tête, mais il a oublié de le mettre le fichier de mise en œuvre. comme NSString* const [email protected]"someString";
Ceci l'a résolu.
ranlib -c libwhatever.a
est un correctif solide pour le problème. J'ai eu le même problème lors de la construction de la bibliothèque PJSIP pour iOS. Ce type de bibliothèque utilise un système make basé sur autoconf, mais nécessite un peu de peaufinage de divers fichiers pour que tout se passe bien pour iOS. Dans le processus de faire cela, j'ai réussi à supprimer la ligne ranlib dans la règle pour les bibliothèques, puis a commencé à obtenir une erreur dans le lien de mon projet sur _PJ_NO_MEMORY_EXCEPTION référencé de _PJ_NO_MEMORY_EXCEPTION$non_lazy_ptr étant indéfini. L'ajout de la ligne ranlib au fichier de bibliothèque a permis de résoudre le problème. Maintenant, mon entrée complète pour LIBS dans les règles.mak est
$(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)
Hope this helps autres aussi essayer d'utiliser UNIX générale configuré bibliothèques externes avec l'iPhone ou iOS.