Saya melakukan langkah yang sama bertahun-tahun lalu. Inilah beberapa hal yang saya alami:
Rata-rata desktop Linux Anda memiliki pengguna yang lebih kaya daripada OS X.
Anda mungkin akan kehilangan alat yang berbeda dari yang saya lakukan, jadi tidak masuk akal untuk mendapatkan rekomendasi tentang penggantian.
Sebaliknya, cukup instal Fink , MacPorts , atau Homebrew hal pertama. Sistem ini menyediakan sistem manajemen paket khas Linux atau BSD. Masing-masing memiliki citarasa dan paket sendiri, sehingga pilihan yang tepat akan didasarkan pada selera dan kebutuhan Anda.
Anda mungkin menemukan bahwa tidak ada satu sistem paket akan memiliki setiap program yang Anda butuhkan. Beberapa program belum porting ke OS X, jadi mereka tidak akan muncul di sistem paket apa pun . Namun demikian, sistem ini sangat memperluas apa yang dikirim dengan OS X, dan akan memudahkan transisi Anda dari Linux.
Kompiler baris perintah OS X sekarang membangun executable 64-bit secara default.
Di Leopard dan sebelumnya, kompiler membuat executable 32-bit sebagai default. Ini dapat menyebabkan masalah dalam beberapa cara: mungkin Anda memiliki perpustakaan 32-bit lama yang tidak dapat Anda bangun kembali tetapi harus terhubung, mungkin Anda masih menjalankan sistem Anda dalam mode 32-bit, dll.
Salah satu cara untuk memaksa build 32-bit adalah dengan mengesampingkan gccdefault dalam sistem build dengan gcc-4.0, yang menjadi compiler Leopard 32-bit-by-default. ( gccadalah symlink ke 64-bit-secara-default gcc-4.2pada Snow Leopard.) Dengan sistem build berbasis autoconf, ini berfungsi:
$ ./configure CC=gcc-4.0 CXX=g++-4.0
(Anda hanya perlu CXXbit jika program berisi komponen C ++.)
Cara lain adalah dengan meneruskan -m32ke kompiler dan tautan:
$ ./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
Ini lebih banyak mengetik, tetapi memungkinkan Anda mendapatkan build 32-bit dari GCC yang lebih baru.
Tautan dinamis sangat berbeda.
Jika Anda adalah orang yang menulis ldperintah dengan tangan, saatnya untuk menghentikan kebiasaan itu. Anda seharusnya menautkan program dan pustaka melalui kompiler, atau menggunakan perantara seperti libtool. Ini menangani perbedaan skema tautan platform-khusus niggly, sehingga Anda dapat menghemat daya otak untuk program pembelajaran yang tidak dapat Anda abaikan dengan mekanisme portabel.
Misalnya, Anda harus memperbarui memori otot Anda sehingga Anda mengetik otool -L someprogramalih-alih ldd someprogramuntuk mencari tahu apa perpustakaan someprogramterhubung.
Perbedaan lain dalam hubungan dinamis yang akan memelintir otak Anda pada awalnya adalah bahwa pada OS X, lokasi pemasangan untuk perpustakaan dicatat di perpustakaan itu sendiri , dan salinan tautan itu menjadi yang dapat dieksekusi pada waktu tautan. Ini berarti bahwa jika Anda menautkan ke pustaka yang telah diinstal /usr/local/libtetapi Anda ingin mengirimkannya ke pengguna Anda di direktori yang sama dengan yang dapat dieksekusi, Anda perlu mengatakan sesuatu seperti ini sebagai bagian dari proses instalasi Anda:
$ cp /usr/local/lib/libfoo.dylib .
$ install_name_tool -id @loader_path/libfoo.dylib libfoo.dylib
$ make LDFLAGS=-L. relink
Sekarang, sebagian besar di atas mungkin bervariasi untuk sistem build Anda, jadi anggap saja sebagai contoh, daripada resep. Apa yang dilakukan adalah membuat salinan pribadi dari perpustakaan yang kami tautkan, mengubah pengidentifikasi pustaka bersama dari jalur absolut menjadi relatif yang berarti "dalam direktori yang sama dengan yang dapat dieksekusi", lalu memaksa membangun kembali yang dapat dieksekusi terhadap salinan yang dimodifikasi ini. perpustakaan.
install_name_tooladalah perintah inti di sini. Jika Anda ingin menginstal pustaka di ../libdirektori relatif terhadap yang dapat dieksekusi, -idargumennya haruslah @loader_path/../lib/libfoo.dylibsebaliknya.
Joe Di Pol menulis artikel bagus tentang ini , dengan lebih banyak detail.
Tautan dinamis + paket pihak ketiga dapat menyebabkan sakit kepala sejak dini.
Anda cenderung mengalami masalah tautan dinamis sejak awal, segera setelah Anda mulai mencoba menggunakan pustaka dari paket pihak ketiga yang tidak menginstal pustaka ke lokasi standar. MacPorts melakukan ini, misalnya, menginstal pustaka /opt/local/lib, bukan /usr/libatau /usr/local/lib. Saat Anda mengalami ini, perbaikan yang baik untuk masalah ini adalah dengan menambahkan baris seperti berikut ini ke Anda .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 menangani masalah kompatibilitas CPU secara berbeda dari Linux.
Pada Linux 64-bit di mana Anda juga harus mendukung 32-bit untuk alasan apa pun, Anda berakhir dengan dua salinan hal-hal seperti perpustakaan yang perlu berada dalam kedua format, dengan versi 64-bit dalam lib64direktori yang paralel dengan libdirektori tradisional .
OS X memecahkan masalah ini secara berbeda, dengan konsep Universal binary, yang memungkinkan Anda memasukkan banyak binari ke dalam satu file. Saat ini Anda dapat memiliki executable yang mendukung hingga 4 jenis CPU: PowerPC 32- dan 64-bit, plus Intel 32- dan 64-bit.
Sangat mudah untuk membangun binari Universal dengan Xcode, tetapi sedikit merepotkan dengan alat-alat baris perintah. Ini membuat Anda membangun Universal-only Intel dengan sistem build berbasis Autoconf:
$ ./configure --disable-dependency-tracking CFLAGS='-arch i386 -arch x86_64' \
LDFLAGS='-arch i386 -arch x86_64'
Tambahkan -arch ppc -arch ppc64ke CFLAGSdan LDFLAGSjika Anda membutuhkan dukungan PowerPC.
Jika Anda tidak menonaktifkan pelacakan ketergantungan, Anda akhirnya membangun hanya untuk satu platform, karena keberadaan .ofile yang baru dibangun untuk platform pertama meyakinkan make(1)bahwa itu tidak perlu dibangun untuk platform kedua juga. Semuanya harus dibangun dua kali dalam contoh di atas; empat kali untuk biner Universal sepenuhnya, jika Anda masih membutuhkan dukungan PowerPC.
(Info lebih lanjut di Catatan Teknis Apple TN2137 .)
Alat pengembang tidak diinstal pada OS X secara default.
Sebelum Lion, tempat yang paling dapat diandalkan untuk mendapatkan alat dev yang tepat untuk sistem Anda adalah pada cakram OS. Itu adalah pemasangan opsional.
Yang menyenangkan tentang menginstal alat dev dari cakram OS adalah Anda tahu alat itu akan bekerja dengan OS. Apple menjadi Apple, Anda harus memiliki versi terbaru OS untuk menjalankan kompiler terbaru, dan mereka tidak selalu membuat unduhan alat lama yang tersedia, jadi cakram OS sering kali merupakan cara termudah untuk menemukan alat yang tepat untuk diberikan. dev atau kotak uji.
Dengan Lion, mereka mencoba untuk menghapus instalasi media, jadi kecuali Anda membeli versi kunci USB yang mahal, Anda harus mengunduh Xcode dari App Store .
Saya sarankan Anda menyimpan setidaknya beberapa versi Xcode DMG yang Anda unduh. Ketika penerus Lion keluar satu atau tiga tahun karena itu, Anda mungkin menemukan diri Anda tanpa cara untuk menginstal versi Xcode kontemporer pada VM uji Lion. Merencanakan ke depan jika masalah ketersediaan dan kurangnya media OS membuat versi lama Xcode tidak dapat diperoleh.