Ich habe eine fette (32- und 64-bit) Intel-Binärdatei namens myBinary , die auf einer anderen Workstation mit Mac OS X 10.8.2 nicht läuft:
Ich habe es von einer Mac OS X 10.8.2-Workstation mit GCC 4.7.2 kompiliert:
%Vor% Ich habe nm ausgeführt und das Symbol ist nicht definiert:
Was habe ich übersehen oder falsch gemacht, als ich myBinary kompiliert habe? Ich bin mir nicht sicher, was ich mit einem fehlenden Symbol in /usr/lib/libstdc++.6.dylib machen kann - sollte ich die C ++ Bibliothek in myBinary ? Statisch kompiliert haben?
Ja, Sie haben zwei Möglichkeiten, entweder Bibliotheken nicht zu verwenden, die der Kunde nicht haben wird ... (Sie können sie als ein dydd oder ein Rahmenwerk zur Verfügung stellen.)
oder einfach nur statisch die Bibliothek verknüpfen ... das wird tatsächlich am Ende kleiner im Speicher und auf dem Festplattenspeicher sein, wenn Ihr Paket nur ein Prozess ist, weil Sie Symbole entfernen können, die Sie nicht verwenden.
Jeder C ++ - Compiler hat seine eigene Implementierung der Standard-C ++ - Bibliothek. Da Sie einen externen Compiler (GCC 4.7) verwenden, ist seine Bibliothek unter den Standardinstallationen von Mac OS X nicht verfügbar.
Sie haben nur die Wahl, die Bibliothek in Ihrer App zu bündeln oder statisch zu verknüpfen.
Um die Bibliothek mit der App zu bündeln:
Aktualisieren Sie den Installationsnamen der Bibliothek mit install_name_tool
Stellen Sie sicher, dass Ihre App sie bei Bedarf findet
z. Du kannst die dylib in .app / Contents / Frameworks setzen, den Installationsnamen auf @rpath setzen und deine App mit der -rpath @executable_path/../Frameworks kompilieren.
Ich habe das gleiche Problem beim Kompilieren auf 10.6 mit MacPorts GCC 4.8 und dann versucht, meine Anwendung auf einer neuen 10.9-Installation ohne MacPorts auszuführen. Zum Glück habe ich Ihre Frage gefunden, und Kentzos Antwort hat mich in die richtige Richtung gelenkt, warum das Problem auftrat ... aber es lieferte nicht die Lösung, nach der ich suchte.
Zuerst erkläre ich, warum es auf Ihrem System korrekt läuft: MacPorts hat Ihrem System die Version von libstdc ++ zur Verfügung gestellt, für die GCC 4.7 Symbole bereitstellt, unter / opt / local / lib anstatt / usr / lib. So sieht es für mich aus (mit GCC 4.8 Universal):
%Vor% Und Sie können sehen, wo Ihre Anwendung mit otool -L verlinkt:
Der einfachste Weg, die Portabilität zu verbessern, ist -static-libstdc++ -static-libgcc in Ihrem letzten gcc-Build-Schritt (derjenige, der den Linker aufruft). Sie benötigen beide, weil dynamisches libgcc dynamische libstdc ++ Bindung mit ihm bringt, also ist es nicht genug, einfach statisches libstdc ++ anzufordern. Für eine einfache Anwendung, hier ist wie Ihre gcc-Linie aussehen könnte:
Laut der gcc man-Seite über Linker-Optionen Das statische Binden von libgcc kann Probleme bei der Behandlung von Ausnahmen in Bibliotheken verursachen. Ich habe keine Probleme damit, aber Sie könnten.
Um also Kenzos Weg zu gehen, sollten Sie zuerst das neueste install_name_tool von MacPorts beziehen, damit es nicht durch unbekannte Ladebefehle verwirrt wird:
%Vor%Ändern wir nun den Pfad so, dass er das Verzeichnis der ausführbaren Datei durchsucht:
%Vor%Jetzt müssen Sie diese Dylibs nur noch mit der Anwendung verteilen. Wenn Sie eine .app-Datei erstellen, kopieren Sie die Dylibs in myBinary.app/Contents/MacOS/.
Eine letzte Anmerkung: Wenn Sie Probleme haben, eine gute universelle Binärdatei zu erstellen, ist es möglich, die Architekturen getrennt (mit verschiedenen Compilern und Optionen) zu erstellen und sie dann mit lipo :
%Vor%Tags und Links gcc macos dylib libstdc++ osx-mountain-lion