Я зробив такий самий хід років тому. Ось що я натрапив:
Ваш середній настільний Linux має багатішу користувачу, ніж ОС X.
Ви, мабуть, пропустите інші інструменти, ніж я, тому немає сенсу конкретизувати рекомендації щодо заміни.
Замість цього просто встановіть Fink , MacPorts або Homebrew . Ці системи забезпечують систему управління пакетами, типову для Linux або BSD. Кожен має свій смак та набір упаковок, тому правильний вибір буде залежати від ваших смаків та потреб.
Ви можете виявити, що жодна система пакетів не матиме будь-якої необхідної вам програми. Деякі програми ще не перенесені на ОС X, тому вони не з’являться в жодній пакетній системі. Тим не менш, ці системи значно розширюють те, що поставляється з OS X, і полегшать ваш перехід з Linux.
Тепер компілятори командного рядка OS X створюють 64-бітні виконувані файли за замовчуванням.
У Leopard та більш ранніх версіях компілятори створили 32-бітні виконувані файли за замовчуванням. Це може викликати проблеми декількома способами: можливо, у вас є старі 32-бітні бібліотеки, з якими ви не можете перебудовуватися, але до них потрібно зв’язатися, можливо, ви все ще працюєте з системою в 32-бітному режимі тощо.
Один із способів змусити 32-бітну збірку - це переопрацювання gccзначень за замовчуванням у системах збирання gcc-4.0, що є старим компілятором Leopard 32-бітним за замовчуванням. ( gccє символьним посиланням на 64-бітовий за замовчуванням gcc-4.2у Snow Leopard.) У системах побудови на основі autoconf це працює:
$ ./configure CC=gcc-4.0 CXX=g++-4.0
( CXXБіт вам потрібен лише в тому випадку, якщо програма містить компоненти C ++.)
Ще один спосіб - перейти -m32до компілятора та лінкера:
$ ./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
Це більше вводити текст, але він дозволяє отримувати 32-бітні збірки з новішої GCC.
Динамічна зв'язок сильно відрізняється.
Якщо ти такий, щоб писати ldкоманди вручну, саме час порушити цю звичку. Натомість вам слід зв’язувати програми та бібліотеки через компілятор або використовувати посередника на зразок libtool. Вони піклуються про особливості відмінної схеми зв’язків, що стосуються певної платформи, тому ви можете заощадити сили мозку для навчальних програм, яким не можна відмовитися від портативних механізмів.
Наприклад, вам потрібно буде оновити м’язову пам’ять, щоб ви вводили, otool -L someprogramа ldd someprogramне з'ясовували, до яких бібліотек someprogramпов’язано.
Ще одна відмінність динамічного зв’язку, яке спочатку закрутить ваш мозок, полягає в тому, що в OS X місце встановлення для бібліотеки записується в самій бібліотеці , а лінкер копіює її у виконуваний файл під час посилання. Це означає, що якщо ви посилаєтесь на бібліотеку, яку встановили, /usr/local/libале ви хочете відправити її своїм користувачам у той самий каталог, що і виконуваний файл, вам потрібно сказати щось подібне як частину вашого процесу встановлення:
$ cp /usr/local/lib/libfoo.dylib .
$ install_name_tool -id @loader_path/libfoo.dylib libfoo.dylib
$ make LDFLAGS=-L. relink
Зараз значна частина вищезгаданого може залежати від вашої системи збирання, тому просто візьміть це як приклад, а не рецепт. Для цього потрібно зробити приватну копію бібліотеки, до якої ми посилаємось, змінити свій ідентифікатор спільної бібліотеки з абсолютного шляху на відносний, що означає "у тому самому каталозі, що і виконуваний файл", а потім змушує відновити виконуваний файл проти цієї модифікованої копії бібліотеки.
install_name_toolтут головна команда. Якщо б замість цього ви хотіли встановити бібліотеку в ../libкаталозі відносно виконуваного файлу, замість цього -idповинен бути аргумент @loader_path/../lib/libfoo.dylib.
Джо Ді Пол написав гарну статтю з цього приводу з набагато детальнішою інформацією.
Динамічна зв'язок + пакети сторонніх розробників можуть спричинити головний біль на початку.
Ви, швидше за все, наштовхнетесь на проблеми динамічного зв’язку, як тільки ви почнете намагатися використовувати бібліотеки з сторонніх пакетів, які не встановлюють бібліотеки у стандартні місця. MacPorts робить це, наприклад, встановлюючи бібліотеки в /opt/local/lib, а не /usr/libабо /usr/local/lib. Коли ви стикаєтеся з цим, хорошим рішенням проблеми є додавання таких рядків, як наступні .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 вирішує проблему сумісності процесора інакше, ніж Linux.
У 64-розрядному Linux з будь-якої причини вам також потрібно підтримувати 32-бітну версію, ви отримуєте дві копії речей, як бібліотеки, які мають бути в обох форматах, при цьому 64-бітні версії вимкнено в lib64каталозі, паралельному традиційний libкаталог.
OS X вирішує цю проблему по-різному, завдяки універсальній бінарній концепції, яка дозволяє розміщувати кілька бінарних файлів в один файл. На даний момент ви можете мати виконавчі файли, які підтримують до 4 типів процесора: 32- та 64-розрядний PowerPC, а також 32- та 64-розрядний Intel.
Створити універсальні бінарні файли за допомогою Xcode дуже просто, але це трохи болить інструменти командного рядка. Ви отримуєте універсальну збірку лише для Intel із системами побудови на основі Autoconf:
$ ./configure --disable-dependency-tracking CFLAGS='-arch i386 -arch x86_64' \
LDFLAGS='-arch i386 -arch x86_64'
Додайте -arch ppc -arch ppc64до CFLAGSі, LDFLAGSякщо вам потрібна підтримка PowerPC.
Якщо ви не відключите відстеження залежностей, ви закінчуєте будівництво лише для однієї платформи, оскільки наявність новоспечених .oфайлів для першої платформи переконує, make(1)що її також не потрібно будувати для другої платформи. У вищенаведеному прикладі все повинно будуватися двічі; чотири рази за повністю універсальний бінарний, якщо вам все ще потрібна підтримка PowerPC.
(Докладніше в технічній записці Apple TN2137 .)
Інструменти для розробників не встановлені на OS X за замовчуванням.
До Лева найнадійнішим місцем для отримання правильних інструментів розробки для вашої системи було диски ОС. Вони необов'язкові для встановлення.
Приємна річ у встановленні інструментів розробників з дисків ОС - це те, що ви знаєте, що інструменти будуть працювати з ОС. Якщо Apple є Apple, для запуску найновіших компіляторів ви повинні мати останню версію ОС, і вони не завжди робили доступними завантаження старих інструментів, тому диски з ОС часто є найпростішим способом пошуку потрібних інструментів для даної програми розробник або тестовий ящик.
У Lion вони намагаються покінчити із встановленням медіа, тому, якщо ви не купите дорогу версію USB-ключа, вам доведеться завантажити Xcode з App Store .
Рекомендую зберегти принаймні кілька версій завантажених вами файлів Xcode DMG. Коли наступник Лева вийде через рік-три, то ви можете опинитися без способу встановити сучасну версію Xcode на тесті Lion VM. Плануйте заздалегідь, якщо проблеми з доступністю та відсутність носія ОС зроблять старі версії Xcode інакше недоступними.