2014-05-09 17 views
6

Ich möchte eine .dylib auf OSX bereitstellen, die mit Delphi erstellt wurde. Diese .dylib sollte sein, die durch Anwendungen von Drittanbietern geladen werden kann.Zuverlässige Deployment von Delphi-Generated Dylib auf OSX

Dies wird wie eine doppelte Frage erscheinen, aber nach viel Suche kann ich keine Antwort dafür finden. Es ist das gleiche Problem wie folgt aus: https://forums.embarcadero.com/thread.jspa?messageID=592417

Das Problem ist, dass die .dylib libcgunwind.1.0.dylib erfordert, aber dass es nicht es finden kann, wenn sie von einer Drittanbieter-Anwendung ausgeführt werden. Als Test habe ich versucht, libcgunwind.1.0.dylib in usr/lib zu kopieren, und das hat funktioniert. Wenn OSX die .dylib nicht finden kann, sucht sie immer in usr/lib. Leider möchte ich dies nicht als endgültige Lösung machen, da es erhöhte Berechtigungen erfordern würde, und es scheint mir ein schwerfälliger Umgang mit einem einfachen Problem zu sein.


ein wenig näher Inspizieren, benutzte ich meine otool .dylib zu inspizieren, und es gab mir den folgenden Pfad: @rpath/libcgunwind.1.0.dylib.

Das Problem ist, gibt es keine Buchhaltung für welche Pfade in @rpath aufgelistet werden, wenn Ihre .dylib von einer Anwendung von Drittanbietern ausgeführt wird. Damit dies funktioniert, müsste die Anwendung immer einen absoluten Pfad zu libcgunwind.1.0.dylib bereitstellen.

Die naheliegende Lösung ist install_name_tool zu ersetzen @rpath durch @loader_path. Wenn meine Logik korrekt ist, sollte dies dazu führen, dass meine .dylib immer libcgunwind.1.0.dylib findet, solange sie sich im selben Ordner befinden. Dies macht Sinn, da die .dylib die Aufgabe haben sollte, ihre eigenen Abhängigkeiten zu finden.

Also habe ich versucht, die folgende Befehlszeile:

install_name_tool -change @rpath/libcgunwind.1.0.dylib @loader_path/libcgunwind.1.0.dylib libTest.dylib

und haben diese Nachricht erhalten:

install_name_tool: file not in an order that can be processed (local relocation entries out of place): libTest.dylib

Ich habe einige der Suche um für diese Fehlermeldung, und ich haven‘ Ich konnte keine Informationen darüber finden. Ich muss davon ausgehen, dass install_name_tool einige Konventionen in einem gcc oder llvm gebaut .dylib gefunden erwartet, und dass Delphi-Compiler ist nicht jene Übereinkommen.

Ich habe etwas in Delphis Compiler dccosx gegraben und die Befehlszeilenargumente überprüft, die Delphi an sie sendet, aber ich kann keine sinnvollen Optionen finden. Diese Art, libcgunwind.1.0.dylib zu verwenden, scheint dem Compiler implizit zu sein und nicht etwas, das ich anpassen kann.

Ich behaupte nicht, dass dies der richtige Weg ist, um das Problem anzugehen, das sind nur die neuesten Dinge, die ich ausprobiert habe. Wenn Sie eine andere Möglichkeit haben, das Problem zu umgehen, teilen Sie uns Ihre Ideen mit!

Antwort

3

Das install_name_tool scheint zu erfordern, dass bestimmte Teile der Dylib in einer bestimmten Reihenfolge wie "lokale Verschiebungseinträge" dann "Symboltabelle", "lokale Symbole", ... sind Die Fehlermeldung bedeutet, dass diese Bestellung nicht als ist erwartet.

Mein Vorschlag ist, dass Sie versuchen, die Dylib-Datei zu patchen. Ich mache das immer mit ausführbaren OSX-Dateien, weil ich ihnen sagen muss, mit welchen Dylib-Versionen sie kompatibel sind.Dies behebt einige Fehler in einer Delphi OSX-Anwendung. Eine Dylib hat eine sehr ähnliche Struktur wie die ausführbare Datei. Ich habe die Erfahrung gemacht, dass das Patchen dieser Dateien nicht so kompliziert ist, wie es sich anhört.

Sie können die Beschreibung der Dateistruktur finden Sie hier: https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html

Der LC_LOAD_DYLIB Abschnitt ist, was Sie brauchen, zu betrachten. Sie sollten in der Lage sein, die Dylib-Namen durch etwas länger zu ersetzen, da dieser Abschnitt normalerweise eine zusätzliche Auffüllung aufweist.

+0

Interessante Lösung. Ich werde das Kopfgeld für den Fall halten, dass irgendjemand etwas weniger Kompliziertes findet, aber ich befürchte, dass dies die einzige Lösung sein könnte. Ich nehme an, das wäre nicht so schlimm, wenn ich einen Weg finden könnte, es in den Deployment-Prozess zu automatisieren. – AudioGL

+0

Nun, ich habe den Patch ausprobiert, und das hat funktioniert. Ich bange immer noch bei dem Gedanken, dies wiederholt zu tun. Was ist Ihr Prozess für die Bereitstellung einer Anwendung? Machst du Patch-Tools? – AudioGL

+0

Ich habe ein Post-Build-Ereignis in meinen OSX-Projekten: '" D: \ Dev \ OSXPatcher.exe "" $ (OUTPUTPATH) "'. Dann geschieht das Patchen automatisch. –