J'ai fait le même mouvement il y a des années. Voici les choses que j'ai rencontrées:
Votre ordinateur de bureau moyen Linux a un environnement utilisateur plus riche que celui d’OS X.
Vous allez probablement manquer d'outils différents des miens, il est donc inutile de préciser les recommandations de remplacement.
Au lieu de cela, installez simplement Fink , MacPorts ou Homebrew en premier lieu. Ces systèmes fournissent un système de gestion de paquets typique de Linux ou des BSD. Chacune a sa propre saveur et son propre emballage. Le bon choix sera donc basé sur vos goûts et vos besoins.
Vous constaterez peut-être qu’un système de paquet unique n’aura pas tous les programmes dont vous avez besoin. Certains programmes n’ayant pas encore été portés sur OS X, ils ne figureront donc dans aucun système de paquet. Néanmoins, ces systèmes étendent considérablement ce qui est livré avec OS X, et faciliteront votre transition de Linux.
Les compilateurs de ligne de commande OS X créent désormais des exécutables 64 bits par défaut.
Dans Leopard et les versions antérieures, les compilateurs construisaient à la place des exécutables 32 bits. Cela peut poser des problèmes de plusieurs manières: vous avez peut-être d'anciennes bibliothèques 32 bits que vous ne pouvez pas reconstruire mais où vous devez établir une liaison, vous exécutez peut-être votre système en mode 32 bits, etc.
Une façon de forcer une construction 32 bits consiste à remplacer les gccvaleurs par défaut dans les systèmes de construction gcc-4.0, à savoir l'ancien compilateur Leopard 32 bits par défaut. ( gccest un lien symbolique vers 64 bits par défaut gcc-4.2sous Snow Leopard.) Avec les systèmes de construction basés sur autoconf, cela fonctionne:
$ ./configure CC=gcc-4.0 CXX=g++-4.0
(Vous n'avez besoin du CXXbit que si le programme contient des composants C ++.)
Un autre moyen est de passer -m32au compilateur et à l'éditeur de liens:
$ ./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
C'est plus typé, mais cela vous permet d'obtenir des versions 32 bits du nouveau GCC.
Le couplage dynamique est très différent.
Si vous êtes du genre à écrire vos ldcommandes à la main, il est temps de rompre avec cette habitude. Vous devriez plutôt lier des programmes et des bibliothèques via le compilateur, ou utiliser un intermédiaire tel que libtool. Ceux-ci traitent les différences de schémas de liens spécifiques à la plate-forme, de sorte que vous puissiez économiser le cerveau pour des programmes d'apprentissage que vous ne pouvez pas résumer avec des mécanismes portables.
Par exemple, vous devrez mettre à jour votre mémoire musculaire pour pouvoir taper à la otool -L someprogramplace des ldd someprogrambibliothèques someprogramliées.
Une autre différence en termes de liaison dynamique qui tordra votre cerveau au début est que sous OS X, l’emplacement d’installation d’une bibliothèque est enregistré dans la bibliothèque elle - même , et l’éditeur de liens la copie dans l’exécutable au moment de la liaison. Cela signifie que si vous vous connectez à une bibliothèque installée /usr/local/libmais que vous souhaitez l'envoyer à vos utilisateurs dans le même répertoire que l'exécutable, vous devez indiquer quelque chose comme ceci dans le cadre de votre processus d'installation:
$ cp /usr/local/lib/libfoo.dylib .
$ install_name_tool -id @loader_path/libfoo.dylib libfoo.dylib
$ make LDFLAGS=-L. relink
Maintenant, une grande partie de ce qui précède est susceptible de varier en fonction de votre système de génération. Prenez-le donc comme exemple plutôt que comme une recette. Cela crée une copie privée d'une bibliothèque à laquelle nous sommes liés, change son identifiant de bibliothèque partagée d'un chemin absolu à un nom relatif "dans le même répertoire que l'exécutable", puis force la reconstruction de l'exécutable par rapport à cette copie modifiée. de la bibliothèque.
install_name_toolest la commande de base ici. Si vous souhaitez plutôt installer la bibliothèque dans un ../librépertoire relatif à l'exécutable, l' -idargument doit être à la @loader_path/../lib/libfoo.dylibplace.
Joe Di Pol a écrit un bon article à ce sujet , avec beaucoup plus de détails.
Le couplage dynamique + les packages tiers peuvent causer des maux de tête dès le début.
Vous rencontrerez probablement des problèmes de liaison dynamique dès le début, dès que vous commencerez à essayer d’utiliser des bibliothèques de packages tiers qui n’installent pas les bibliothèques dans des emplacements standard. MacPorts fait cela, par exemple, en installant des bibliothèques dans /opt/local/lib, plutôt que /usr/libou /usr/local/lib. Lorsque vous rencontrez ce problème, une bonne solution au problème consiste à ajouter à votre ligne les lignes suivantes .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 traite le problème de compatibilité du processeur différemment de Linux.
Sur un Linux 64 bits où vous devez également prendre en charge 32 bits pour une raison quelconque, vous vous retrouvez avec deux copies d'éléments tels que des bibliothèques qui doivent être dans les deux formats, les versions 64 bits étant désactivées dans un lib64répertoire parallèle au répertoire. librépertoire traditionnel .
OS X résout ce problème différemment, avec le concept de binaire universel, qui permet de placer plusieurs fichiers binaires dans un seul fichier. Vous pouvez actuellement utiliser des exécutables prenant en charge jusqu'à 4 types de processeurs: PowerPC 32 et 64 bits, plus Intel 32 et 64 bits.
Il est facile de créer des fichiers binaires Universal avec Xcode, mais un peu pénible avec les outils de ligne de commande. Cela vous donne une construction Universal Intel uniquement avec des systèmes de construction basés sur Autoconf:
$ ./configure --disable-dependency-tracking CFLAGS='-arch i386 -arch x86_64' \
LDFLAGS='-arch i386 -arch x86_64'
Ajoutez -arch ppc -arch ppc64à la CFLAGSet LDFLAGSsi vous avez besoin du support PowerPC.
Si vous ne désactivez pas le suivi des dépendances, vous ne construisez que pour une plate-forme, car la présence de .ofichiers nouvellement générés pour la première plate-forme convainc make(1)qu'il n'est pas nécessaire de créer pour la deuxième plate-forme également. Tout doit être construit deux fois dans l'exemple ci-dessus; quatre fois pour un binaire entièrement universel, si vous avez toujours besoin de la prise en charge de PowerPC.
(Plus d'informations dans la note technique TN2137 de Apple .)
Les outils de développement ne sont pas installés sur OS X par défaut.
Avant Lion, les disques du système d'exploitation étaient l'endroit le plus fiable pour obtenir les bons outils de développement pour votre système. Ils sont une installation facultative.
La bonne chose à propos de l'installation des outils de développement à partir des disques du système d'exploitation est que vous savez que ces outils fonctionneront avec le système d'exploitation. Apple étant Apple, vous devez disposer d’une version récente du système d’exploitation pour pouvoir utiliser les derniers compilateurs. Ils n’ont pas toujours téléchargé les anciens outils. Les disques du système d’exploitation constituent donc souvent le moyen le plus simple de trouver les bons outils pour dev ou test box.
Avec Lion, ils essaient d’éliminer le support d’installation. À moins d’acheter la version coûteuse de la clé USB, vous devrez donc télécharger Xcode sur l’App Store .
Je vous recommande de conserver au moins quelques versions de tout XGG DMG que vous téléchargez. Lorsque le successeur de Lion sort dans un an ou trois, vous risquez donc de ne pas avoir le moyen d'installer une version contemporaine de Xcode sur une machine virtuelle de test Lion. Planifiez à l'avance au cas où les problèmes de disponibilité et le manque de support du système d'exploitation rendaient les anciennes versions de Xcode autrement introuvables.