ist beim Entwickeln ein echtes Problem.
Frameworks unter Mac OS X werden schließlich so gelinkt, das jeder Framework den Pfad enthält, an dem er später einmal leben wird - und dieser Pfad wird dann in die Applikation eingetragen die ihn laden möchte.
Das ist blöd, wenn man Frameworks in /Library/Frameworks/
installiert, bei der Entwicklung dann aber mal eine andere Version ausprobieren will oder muss. Auch klassisch ist, dass ein Framework der von Apple kommt zu alt ist und man sicherstellen muss, das ein eigener Framework stattdessen verwendet wird, der Bugfixes enthält.
Schwierig.
Nunja, man macht das unter OS X mit dem Äquivalent des Linux Konstrukts LD_LIBRARY_PATH
, also diversen Umgebungsvariablen, mit denen man das Verhalten des dynamischen linkers beeinflussen kann. Spaßigerweise hat Apple das verhalten des dynamischen Linkers unter Tiger (10.4) verändert, dass er sich jetzt genauso verhält wie unter Leopard (10.5) - zumindest sagt mein Gedächtnis andere Dinge als die 10.4 manpage von dyld
.
Also sind jetzt eigentlich nur noch zwei Umgebungsvariablen interessant:
DYLD_FRAMEWORK_PATH
wenn man etwas laden will, bevor die Pfade verwendet werden die in der Applikation für einen Framework stehen -> also um einen Framework zu überschreiben.DYLD_FALLBACK_FRAMEWORK_PATH
wenn man etwas nachladen will, nachdem es an den vorgegebenen Pfaden nicht gefunden wurde. Die Manpage ist mir da noch nicht 100% klar - es wirkt fast so, als könnte man dyld auch dafür verwenden eine neuere Version anzugeben, die nur genutzt wird, wenn in der alten ein bestimmtes Symbol nicht gefunden wurde - das konnte ich aber noch nicht testen (und kommt mir auch komisch vor).
Also: kennen sollte man die - das gibt viel flexibilität.