Ho fatto la stessa mossa anni fa. Ecco le cose che ho incontrato:
Il tuo desktop Linux medio ha un'area utente più ricca di quella di OS X.
Probabilmente ti mancheranno strumenti diversi rispetto a me, quindi non ha senso ottenere specifici consigli per le sostituzioni.
Invece, installa Fink , MacPorts o Homebrew per prima cosa. Questi sistemi forniscono un sistema di gestione dei pacchetti tipico di Linux o dei BSD. Ognuno ha il suo sapore e il suo set di pacchetti, quindi la scelta giusta si baserà sui tuoi gusti e bisogni.
Potresti scoprire che nessun sistema di pacchetti avrà tutti i programmi di cui hai bisogno. Alcuni programmi devono ancora essere trasferiti su OS X, quindi non verranno visualizzati in nessun sistema di pacchetti. Tuttavia, questi sistemi estendono notevolmente ciò che viene fornito con OS X e faciliteranno la transizione da Linux.
I compilatori della riga di comando di OS X ora creano eseguibili a 64 bit per impostazione predefinita.
In Leopard e versioni precedenti, i compilatori hanno invece creato eseguibili a 32 bit per impostazione predefinita. Ciò può causare problemi in diversi modi: forse hai vecchie librerie a 32 bit che non puoi ricostruire ma a cui devi collegarti, forse stai ancora eseguendo il tuo sistema in modalità 32 bit, ecc.
Un modo per forzare una build a 32 bit è quello di sostituire le gccimpostazioni predefinite nei sistemi di build gcc-4.0, ovvero il vecchio compilatore Leopard a 32 bit per impostazione predefinita. ( gccè un collegamento simbolico ai 64 bit di default gcc-4.2su Snow Leopard.) Con i sistemi di build basati su autoconf, funziona:
$ ./configure CC=gcc-4.0 CXX=g++-4.0
(È necessario il CXXbit solo se il programma contiene componenti C ++.)
Un altro modo è passare -m32al compilatore e al linker:
$ ./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
È più digitazione, ma ti consente di ottenere build a 32 bit dal più recente GCC.
Il collegamento dinamico è molto diverso.
Se sei il tipo di scrivere i tuoi ldcomandi a mano, è tempo di rompere quell'abitudine. Dovresti invece collegare programmi e librerie tramite il compilatore o utilizzare un intermediario come libtool. Questi si occupano delle differenze dello schema di collegamento specifiche della piattaforma, quindi puoi risparmiare il potere del cervello per i programmi di apprendimento che non puoi sottrarre ai meccanismi portatili.
Ad esempio, dovrai aggiornare la memoria muscolare in modo da digitare otool -L someprograminvece di ldd someprogramcapire a cosa someprogramsono collegate le librerie .
Un'altra differenza nel collegamento dinamico che inizialmente ti tormenterà il cervello è che su OS X, il percorso di installazione di una libreria è registrato nella libreria stessa e il linker lo copia nell'eseguibile al momento del collegamento. Ciò significa che se si collega a una libreria che è stata installata /usr/local/libma si desidera spedirla ai propri utenti nella stessa directory dell'eseguibile, è necessario dire qualcosa del genere come parte del processo di installazione:
$ cp /usr/local/lib/libfoo.dylib .
$ install_name_tool -id @loader_path/libfoo.dylib libfoo.dylib
$ make LDFLAGS=-L. relink
Ora, molto di quanto sopra probabilmente varierà per il tuo sistema di compilazione, quindi prendilo come esempio, piuttosto che come ricetta. Ciò che fa è creare una copia privata di una libreria a cui ci colleghiamo, cambia l'identificatore della libreria condivisa da un percorso assoluto in uno relativo che significa "nella stessa directory dell'eseguibile", quindi forza una ricostruzione dell'eseguibile rispetto a questa copia modificata della biblioteca.
install_name_toolè il comando principale qui. Se invece si desidera installare la libreria in una ../libdirectory relativa all'eseguibile, l' -idargomento dovrebbe essere @loader_path/../lib/libfoo.dylibinvece.
Joe Di Pol ha scritto un buon articolo su questo , con molti più dettagli.
Collegamento dinamico + pacchetti di terze parti possono causare mal di testa all'inizio.
È probabile che si verifichino problemi di collegamento dinamico all'inizio, non appena si inizia a provare a utilizzare librerie da pacchetti di terze parti che non installano le librerie in percorsi standard. MacPorts fa questo, ad esempio, l'installazione di librerie in /opt/local/lib, invece di /usr/libo /usr/local/lib. Quando ti imbatti in questo, una buona soluzione per il problema è quella di aggiungere linee come la seguente al tuo .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 gestisce il problema di compatibilità della CPU in modo diverso rispetto a Linux.
Su un Linux a 64 bit in cui è necessario supportare anche a 32 bit per qualsiasi motivo, si ottengono due copie di cose come librerie che devono essere in entrambi i formati, con le versioni a 64 bit disattivate in una lib64directory parallela alla libdirectory tradizionale .
OS X risolve questo problema in modo diverso, con il concetto binario Universal, che consente di inserire più file binari in un singolo file. Attualmente è possibile avere file eseguibili che supportano fino a 4 tipi di CPU: PowerPC a 32 e 64 bit, oltre a Intel a 32 e 64 bit.
È facile costruire binari universali con Xcode, ma è un po 'una seccatura con gli strumenti da riga di comando. Questo ti dà una build solo Intel universale con sistemi di build basati su Autoconf:
$ ./configure --disable-dependency-tracking CFLAGS='-arch i386 -arch x86_64' \
LDFLAGS='-arch i386 -arch x86_64'
Aggiungi -arch ppc -arch ppc64a CFLAGSe LDFLAGSse hai bisogno del supporto PowerPC.
Se non disabiliti il rilevamento delle dipendenze, finisci per costruire solo per una piattaforma, poiché la presenza di .ofile di nuova make(1)creazione per la prima piattaforma convince che non è necessario costruire anche per la seconda piattaforma. Tutto deve essere costruito due volte nell'esempio sopra; quattro volte per un binario completamente universale, se hai ancora bisogno del supporto PowerPC.
(Maggiori informazioni nella nota tecnica Apple TN2137 .)
Gli strumenti per sviluppatori non sono installati su OS X per impostazione predefinita.
Prima di Lion, il posto più affidabile per ottenere gli strumenti di sviluppo giusti per il tuo sistema era sui dischi del sistema operativo. Sono un'installazione opzionale.
La cosa bella dell'installazione degli strumenti di sviluppo dai dischi del sistema operativo è che sai che gli strumenti funzioneranno con il sistema operativo. Essendo Apple, devi disporre di una versione recente del sistema operativo per eseguire gli ultimi compilatori e non hanno sempre reso disponibili download di vecchi strumenti, quindi i dischi del sistema operativo sono spesso il modo più semplice per trovare gli strumenti giusti per un determinato dev o box di prova.
Con Lion, stanno cercando di eliminare i supporti di installazione, quindi a meno che non acquisti la costosa versione della chiave USB, dovrai scaricare Xcode dall'App Store .
Ti consiglio di conservare almeno alcune versioni di qualsiasi DMG Xcode scaricato. Quando il successore di Lion uscirà tra un anno o tre, potresti ritrovarti senza un modo per installare una versione contemporanea di Xcode su una VM di prova Lion. Pianificare in anticipo nel caso in cui i problemi di disponibilità e la mancanza di supporti del sistema operativo rendano altrimenti introvabili le vecchie versioni di Xcode.