Wie kann man bei Xcode 6.1 steuern was bei "Run" als DYLD_FRAMEWORK_PATH gesetzt wird?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Wie kann man bei Xcode 6.1 steuern was bei "Run" als DYLD_FRAMEWORK_PATH gesetzt wird?

    Ich habe ein Programm wo es Probleme mit gleichbenannten Frameworks gibt. Compile und Link habe ich hingebracht. Jetzt gibts nur noch ein Problem:

    wenn ich das Programm unter Xcode 6.1 (unter 10.9.5) mit "Run" ausführen lasse, dann ist der DYLD_FRAMEWORK_PATH anders als wenn ich das Programm vom Terminal aus starte.
    Entsprechend unterschiedlich verhält es sich auch.

    Ich habe nun versucht im Edit Scheme... die Environment-Variablen zu setzen. Das geht auch für DYLD_FRAMEWORK_PATH, sogar auf "". Nur fügt Xcode da dann einfach seine Default-Werte hinten an (und ggf. einen : dazwischen). D.h. wie bringe ich Xcode dazu ein Programm mit festem DYLD_FRAMEWORK_PATH zu starten ohne meine Einstellung zu verändern?

    Unter den Target / Build-Settings habe ich auch nichts gefunden (wie auch, da das "Run" ja vom Scheme abhängt).

    Danke,
    hns

    PS: es ist auch nicht leicht herauszufinden unter welchem Environment das läuft. Die Lösung: einen Breakpoint setzen und im lldb eingeben:

    Quellcode

    1. (lldb) po [[NSProcessInfo processInfo] environment]
  • Marco Feltmann schrieb:

    Hast Du mal versucht, das hart über die LSEnvironment in der App-Info.plist einzutragen?
    Nee, noch nicht weil ich mir nicht mehr sicher bin ob der DYLD_FRAMEWORK_PATH überhaupt ist.

    Ich habe nämlich versucht, alle Environment-Variablen durch ein Wrapper-Script nachzubauen )incl. DYLD_FRAMEWORK_PATH, current directory und allen sonstigen Unterschieden).

    Dennoch gibt es einen Unterschied welche Frameworks geladen werden. Selbst wenn die "env"-Ausgabe im lldb identisch ist.
    D.h. der DYLD_FRAMEWORK_PATH ist vielleicht nicht mal der richtige Hebel.

    Wenn ich das unter Xcode starte und die Prozeß-IDs anschaue, dann ist das Programm das sich im Xcode als lldb meldet ganz kompliziert eingebunden:

    /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver

    Und der setzt vielleicht noch das eine oder andere bevor er mein Programm startet. Vermutlich irgendeine .llldb_conf die ich erst mal nicht sehe. Wenn ich in der Aktivitätsanzeige die geöffneten Files anzeige ist auch nichts aufschlussreiches dabei :(

    Aber in der Liste der offenen Files meiner Applikation. Wenn ich sie unter Xcode starte gibts zusätzlich (in meiner App!):

    /Applications/Xcode.app/Contents/Developer/usr/lib/libBacktraceRecording.dylib
    /Applications/Xcode.app/Contents/PlugIns/DebuggerUI.ideplugin/Contents/Resources/libViewDebuggerSupport.dylib

    Und evtl. spielt aber auch das hier eine (unbekannte) Rolle:

    /private/var/db/dyld/dyld_shared_cache_x86_64

    Dann habe ich noch

    Quellcode

    1. po [NSBundle allFrameworks]
    probiert und dann sind deutlich mehr Frameworks geladen wenn ich den Xcode lldb benutze (selbst bei identischen PATHs durch das Wrapper-Script).

    Tja, jetzt fehlt nur der Schalter um den Mechanismus abzuschalten, der meine App dazu bringt mehr Frameworks zu laden wenn ich innerhalb Xcode debuggen will (also ein Child-Prozeß von debugserver ist)l :)

    -- hns
  • Wenn du deine App im Debugger startest ist es normal, das mehr Frameworks/Libraries geladen werden, irgendwie muss der Debugger ja die ganzen schönen Features unterstützen.

    Du kannst im übrigen auch deine App normal starten und dann den debugger nachträglich anhängen. Keine Ahnung ob das bei deinem Problem hilft.

    Allerdings würde ich ehr versuchen herraus zufinden, wieso deine App sich mit den zusätzlich geladenen Frameworks/Code durch den Debugger anders verhält. Das klingt ehr nach einen Fehler in deinem Code bzw. falschen Annahmen die du stellst.
  • Naja, der Fehler ist doch aus dem ersten Beitrag ersichtlich.
    Die App nutzt ein Framework, welches den gleichen Namen hat wie ein Framework, das Xcode dazu linkt.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • kleinweby schrieb:

    Wenn du deine App im Debugger startest ist es normal, das mehr Frameworks/Libraries geladen werden, irgendwie muss der Debugger ja die ganzen schönen Features unterstützen.

    Du kannst im übrigen auch deine App normal starten und dann den debugger nachträglich anhängen. Keine Ahnung ob das bei deinem Problem hilft.

    Allerdings würde ich ehr versuchen herraus zufinden, wieso deine App sich mit den zusätzlich geladenen Frameworks/Code durch den Debugger anders verhält. Das klingt ehr nach einen Fehler in deinem Code bzw. falschen Annahmen die du stellst.

    Naja, der Unterschied ist nicht ob ich es ohne oder mit Debugger starte sondern ob ich lldb von der Kommandozeile heraus oder über Xcode starte. Und das sollte m.E. gleich sein. Denn die neuen Features setzt der Xcode auf den lldb oben drauf und sollte da nichts in meine App einschleusen. Codefehler ist es definitiv nicht.

    Und wenn ich den Xcode an die laufende App anhänge tritt das auch nicht auf (sie wurde ja nicht vom debugserver gestartet). Das könnte ich zwar zum Debugging nutzen, aber ist etwas umständlich zu bedienen, da es nicht mehr reicht einen Breakpoint zu setzen und "Run" zu drücken.

    Marco Feltmann schrieb:

    Naja, der Fehler ist doch aus dem ersten Beitrag ersichtlich.
    Die App nutzt ein Framework, welches den gleichen Namen hat wie ein Framework, das Xcode dazu linkt.

    Ja, wobei es hier kein Fehler ist sondern volle Absicht (Nachbau eines Frameworks als OpenSource)... Und ein Problem ist es eben nur wenn ich das alles direkt im Xcode debuggen will. Ich könnte es zwar fürs Debuggin umbenennen, aber das macht andere Probleme.

    -- hns
  • Also ich denke ich habe es gelöst.
    Und weil es ein tieferes Verständnis gibt, wie das Debugging auf Xcode 6.1 intern funktioniert hier eine Erklärung:

    Das Problem ist der Eintrag "View Dbugging / Enable User Interface Debugging" unter den Options im "Edit Scheme..."

    Wenn das angeclickt ist (default), dann fügt der Xcode-Debugger bzw. der debugserver (über einen nicht genauer bekannten Mechanismus) zwei Frameworks ein:

    dyld: loaded: /Applications/Xcode.app/Contents/Developer/usr/lib/libBacktraceRecording.dylib
    dyld: loaded: /Applications/Xcode.app/Contents/PlugIns/DebuggerUI.ideplugin/Contents/Resources/libViewDebuggerSupport.dylib

    Das zweite ist gegen einige System-Frameworks gelinkt und bringt den dyld natürlich dazu die (und weitere Abhängigkeiten) dann auch nachzuladen. Auch wenn man es nirgends in seinen Target-Settings im Projekt angegeben hat kann man also eine ganze Menge Frameworks in seiner App haben.

    Wie findet man das alles heraus?

    1. Unter "Edit Scheme..." bei den "Arguments" die Environment-Variable DYLD_PRINT_LIBRARIES definieren (leerer Inhalt reicht) und das lldb-Log anschauen
    2. otool -L dyld: /Applications/Xcode.app/Contents/PlugIns/DebuggerUI.ideplugin/Contents/Resources/libViewDebuggerSupport.dylib

    Ich hoffe das hilft mal jemand wenn sich ein Programm unter lldb auf der Kommandozeile anders verhält als wenn man es innerhalb von Xcode debuggen will.

    -- hns