Ich habe den gleichen Schritt vor Jahren gemacht. Hier sind die Dinge, auf die ich gestoßen bin:
Ein durchschnittliches Desktop-Linux hat ein umfangreicheres Benutzerland als OS X.
Sie werden wahrscheinlich andere Werkzeuge vermissen als ich, daher macht es keinen Sinn, konkrete Empfehlungen für den Austausch zu erhalten.
Installieren Sie stattdessen einfach zuerst Fink , MacPorts oder Homebrew . Diese Systeme stellen ein für Linux oder die BSDs typisches Paketverwaltungssystem bereit. Jedes hat sein eigenes Geschmacks- und Paketset, sodass die richtige Wahl auf Ihren Geschmack und Ihre Bedürfnisse abgestimmt ist.
Sie werden vielleicht feststellen, dass kein einziges Paketsystem über jedes Programm verfügt, das Sie benötigen. Einige Programme müssen noch auf OS X portiert werden, sodass sie in keinem Paketsystem angezeigt werden. Trotzdem erweitern diese Systeme den Lieferumfang von OS X erheblich und erleichtern Ihnen den Übergang von Linux.
OS X-Befehlszeilencompiler erstellen jetzt standardmäßig ausführbare 64-Bit-Dateien.
In Leopard und früheren Versionen haben die Compiler stattdessen standardmäßig ausführbare 32-Bit-Dateien erstellt. Dies kann auf verschiedene Arten zu Problemen führen: Möglicherweise verfügen Sie über alte 32-Bit-Bibliotheken, die Sie nicht neu erstellen können, auf die Sie jedoch eine Verknüpfung herstellen müssen, möglicherweise wird Ihr System weiterhin im 32-Bit-Modus ausgeführt usw.
Eine Möglichkeit, einen 32-Bit-Build zu erzwingen , besteht darin, die Standardeinstellungen gccin Buildsystemen mit gcc-4.0dem alten 32-Bit-Leopard-Compiler zu überschreiben . ( Dies gccist ein Symlink zur 64-Bit-Standardeinstellung gcc-4.2von Snow Leopard.) Mit auf Autoconf basierenden Build-Systemen funktioniert Folgendes:
$ ./configure CC=gcc-4.0 CXX=g++-4.0
(Sie benötigen das CXXBit nur, wenn das Programm C ++ - Komponenten enthält.)
Eine andere Möglichkeit ist die Übergabe -m32an den Compiler und den Linker:
$ ./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
Es ist mehr tippend, aber es lässt Sie 32-Bit-Builds aus dem neueren GCC herausholen.
Dynamische Verknüpfung ist sehr unterschiedlich.
Wenn Sie Ihre ldBefehle von Hand schreiben , ist es Zeit, diese Gewohnheit zu brechen. Sie sollten stattdessen Programme und Bibliotheken über den Compiler verknüpfen oder einen Vermittler wie libtool. Diese kümmern sich um die winzigen plattformspezifischen Unterschiede beim Verbindungsschema, sodass Sie die Gehirnleistung für Lernprogramme sparen können, die Sie mit tragbaren Mechanismen nicht abstrahieren können.
Zum Beispiel müssen Sie Ihr Muskelgedächtnis aktualisieren, damit Sie es eingeben können, otool -L someprogramanstatt ldd someprogramherauszufinden, mit welchen Bibliotheken someprogrames verknüpft ist.
Ein weiterer Unterschied bei der dynamischen Verknüpfung, der Ihr Gehirn zunächst verdreht, besteht darin, dass unter OS X der Installationsort für eine Bibliothek in der Bibliothek selbst aufgezeichnet wird und der Linker diesen zum Zeitpunkt der Verknüpfung in die ausführbare Datei kopiert. Dies bedeutet, dass Sie, wenn Sie eine Verknüpfung zu einer Bibliothek herstellen, die in installiert wurde, diese /usr/local/libjedoch im selben Verzeichnis wie die ausführbare Datei an Ihre Benutzer senden möchten, im Rahmen Ihres Installationsvorgangs Folgendes sagen müssen:
$ cp /usr/local/lib/libfoo.dylib .
$ install_name_tool -id @loader_path/libfoo.dylib libfoo.dylib
$ make LDFLAGS=-L. relink
Nun ist es wahrscheinlich, dass viele der oben genannten Punkte für Ihr Build-System variieren. Nehmen Sie es also als Beispiel und nicht als Rezept. Dies bewirkt, dass eine private Kopie einer Bibliothek, mit der wir eine Verknüpfung herstellen, die Kennung der gemeinsam genutzten Bibliothek von einem absoluten in einen relativen Pfad geändert wird, was "im selben Verzeichnis wie die ausführbare Datei" bedeutet, und anschließend eine Neuerstellung der ausführbaren Datei für diese geänderte Kopie erzwungen wird der Bibliothek.
install_name_toolist der Kernbefehl hier. Wenn Sie die Bibliothek stattdessen in einem ../libVerzeichnis relativ zur ausführbaren Datei installieren -idmöchten, muss das Argument @loader_path/../lib/libfoo.dylibstattdessen lauten .
Joe Di Pol hat einen guten Artikel dazu geschrieben , mit viel mehr Details.
Dynamische Verknüpfung und Pakete von Drittanbietern können frühzeitig Kopfschmerzen verursachen.
Es ist wahrscheinlich, dass Sie frühzeitig auf Probleme mit dynamischen Verknüpfungen stoßen, sobald Sie versuchen, Bibliotheken aus Paketen von Drittanbietern zu verwenden, bei denen die Bibliotheken nicht an Standardspeicherorten installiert werden. MacPorts tut dies zum Beispiel der Installation von Bibliotheken in /opt/local/lib, anstatt /usr/liboder /usr/local/lib. Wenn Sie darauf stoßen, besteht eine gute Lösung für das Problem darin, Ihrer Liste folgende Zeilen hinzuzufügen .bash_profile:
# Tell the dynamic linker (dyld) where to find MacPorts package libs
export DYLD_LIBRARY_PATH=/opt/local/lib:$DYLD_LIBRARY_PATH
# Add MacPorts header file install dirs to your gcc and g++ include paths
export C_INCLUDE_PATH=/opt/local/include:$C_INCLUDE_PATH
export CPLUS_INCLUDE_PATH=/opt/local/include:$CPLUS_INCLUDE_PATH
OS X behandelt das CPU-Kompatibilitätsproblem anders als Linux.
Auf einem 64-Bit-Linux, auf dem Sie aus irgendeinem Grund auch 32-Bit unterstützen müssen, erhalten Sie zwei Kopien von Dingen wie Bibliotheken, die in beiden Formaten vorliegen müssen. Die 64-Bit-Versionen befinden sich in einem lib64Verzeichnis parallel zum traditionelles libVerzeichnis.
OS X löst dieses Problem auf unterschiedliche Weise. Mit dem Universal Binary-Konzept können Sie mehrere Binärdateien in eine einzige Datei einfügen. Sie können derzeit ausführbare Dateien haben, die bis zu 4 CPU-Typen unterstützen: 32- und 64-Bit-PowerPC sowie 32- und 64-Bit-Intel.
Es ist einfach, Universal-Binärdateien mit Xcode zu erstellen, aber mit Kommandozeilen-Tools ist das ein bisschen mühsam. Dadurch erhalten Sie einen universellen Intel-Build mit Autoconf-basierten Buildsystemen:
$ ./configure --disable-dependency-tracking CFLAGS='-arch i386 -arch x86_64' \
LDFLAGS='-arch i386 -arch x86_64'
Ergänzen Sie -arch ppc -arch ppc64das CFLAGSund, LDFLAGSwenn Sie PowerPC-Unterstützung benötigen.
Wenn Sie die Abhängigkeitsnachverfolgung nicht deaktivieren, wird nur für eine Plattform erstellt, da das Vorhandensein neu erstellter .oDateien für die erste Plattform davon überzeugt ist, make(1)dass sie nicht auch für die zweite Plattform erstellt werden müssen. Im obigen Beispiel muss alles zweimal gebaut werden. vier Mal für eine vollständig universelle Binärdatei, wenn Sie weiterhin PowerPC-Unterstützung benötigen.
(Weitere Informationen finden Sie im technischen Hinweis TN2137 von Apple .)
Die Entwicklertools werden standardmäßig nicht unter OS X installiert.
Vor Lion war der zuverlässigste Ort, um die richtigen Entwickler-Tools für Ihr System zu erhalten, auf den Betriebssystem-Disks. Sie sind eine optionale Installation.
Das Schöne an der Installation der Dev-Tools von den Betriebssystem-Disks ist, dass Sie wissen, dass die Tools mit dem Betriebssystem funktionieren. Apple Da es sich um Apple handelt, muss eine aktuelle Version des Betriebssystems vorhanden sein, um die neuesten Compiler ausführen zu können, und es wurden nicht immer Downloads von alten Tools zur Verfügung gestellt. Daher sind die Betriebssystem-Disks häufig der einfachste Weg, die richtigen Tools für eine bestimmte Anwendung zu finden dev oder test box.
Mit Lion versuchen sie, Installationsmedien zu beseitigen. Wenn Sie also nicht die teure USB-Stick-Version kaufen, müssen Sie Xcode aus dem App Store herunterladen .
Ich empfehle, dass Sie mindestens einige Versionen aller heruntergeladenen Xcode-DMGs behalten. Wenn der Nachfolger von Lion ein oder drei Jahre später herauskommt, haben Sie möglicherweise keine Möglichkeit, eine zeitgleiche Version von Xcode auf einer Lion-Test-VM zu installieren. Planen Sie voraus, falls die Verfügbarkeitsprobleme und das Fehlen von Betriebssystemmedien dazu führen, dass alte Versionen von Xcode ansonsten nicht mehr erhältlich sind.