3
Warum macht Leopard einige Symbole mit $ non_lazy_ptr aus? Noch wichtiger: Was ist die beste Methode, um nicht definierte Symbolfehler zu beheben, weil ein Symbol mit $ non_lazy_ptr manipuliert wurde?
A
Antwort
5
Von: Developer Connection - Indirect Addressing
Indirekte Adressierung ist der Name der Code-Generierung Technik, die in einer Datei ermöglicht definierte Symbole aus einer anderen Datei referenziert werden, ohne dass die Referenzierung Datei explizite Kenntnis der Layout der Datei hat Das definiert das Symbol. Daher kann die definierende Datei unabhängig von der referenzierenden Datei modifiziert werden. Die indirekte Adressierung minimiert die Anzahl der Standorte, die vom dynamischen Linker geändert werden müssen. Dadurch wird die gemeinsame Nutzung von Code erleichtert und die Leistung verbessert.
Wenn eine Datei Daten verwendet, die in einer anderen Datei definiert sind, werden Symbolreferenzen erstellt. Eine Symbolreferenz identifiziert die Datei, aus der ein Symbol importiert wird, und das referenzierte Symbol. Es gibt zwei Arten von Symbolreferenzen: nonlazy und faul.
Nicht lazy-Symbolreferenzen werden beim Laden eines Moduls vom dynamischen Linker aufgelöst (an ihre Definitionen gebunden). Eine nonlazy Symbolreferenz ist im Wesentlichen ein Symbolzeiger - ein zeigergroßes Stück Daten. Der Compiler erzeugt nicht aktuelle Symbolreferenzen für Datensymbole oder Funktionsadressen.
Lazy-Symbolreferenzen werden vom Dynamic Linker bei der ersten Verwendung (nicht zur Ladezeit) aufgelöst. Nachfolgende Aufrufe des referenzierten Symbols springen direkt zur Definition des Symbols. Faule Symbolreferenzen bestehen aus einem Symbolzeiger und einem Symbolstub, einer kleinen Menge Code, der direkt den Symbolzeiger dereferenziert und durch den Symbolzeiger springt. Der Compiler erzeugt träge Symbolreferenzen, wenn er auf einen Aufruf einer in einer anderen Datei definierten Funktion stößt.
3
In der menschlichen Sprache: der Compiler generiert Stubs mit $ non_lazy_ptr angehängt, um die Verknüpfung zu beschleunigen. Sie sehen wahrscheinlich, dass die Funktion Foo, auf die von _Foo $ non_lazy_ptr verwiesen wird, nicht definiert ist, oder etwas Ähnliches - das sind nicht die gleichen Dinge. Stellen Sie sicher, dass das Symbol tatsächlich in den Objektdateien/Bibliotheken, mit denen Sie Ihre App verknüpfen, deklariert und exportiert wird. Zumindest war das mein Problem, ich dachte auch, dass es eine seltsame Linker-Sache ist, bis ich feststellte, dass mein Problem anderswo war - es gibt mehrere andere mögliche Ursachen, die bei Google gefunden wurden.
0
ranlib -c auf Ihrer Bibliotheksdatei behebt das Problem
1
Wenn jemand anderes das gleiche Problem stolpert ich hatte:
Hatte eine extern NSString* const someString; in der Header-Datei, aber vergessen sie die Umsetzung Datei zu setzen. als NSString* const [email protected]"someString";
Dies löste es.
2
ranlib -c libwhatever.a
ist eine solide Lösung für das Problem. Ich hatte das gleiche Problem beim Erstellen der PJSIP-Bibliothek für iOS. Diese Bibliothekssortierung verwendet ein Autoconf-basiertes make-System, benötigt jedoch ein paar Feineinstellungen für verschiedene Dateien, um alles für iOS in Ordnung zu bringen. Dabei habe ich es geschafft, die ralib-Zeile in der Regel für Bibliotheken zu entfernen und dann einen Fehler in der Verknüpfung meines Projekts zu bekommen, der über _PJ_NO_MEMORY_EXCEPTION referenziert von _PJ_NO_MEMORY_EXCEPTION$non_lazy_ptr undefiniert ist.
Das Hinzufügen der Ranalib-Linie zurück zur Bibliotheksdatei löste es. Jetzt mein voller Eintrag für LIBS in Regeln.mak ist
$(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)
Hoffe das hilft anderen auch versuchen, allgemeine UNIX konfiguriert externe Bibliotheken mit iPhone oder iOS zu verwenden.