Я сделал то же самое несколько лет назад. Вот вещи, с которыми я столкнулся:
Ваш обычный настольный Linux имеет более богатое пользовательское пространство, чем OS X.
Возможно, вы пропустите другие инструменты, чем я, поэтому нет смысла получать конкретные рекомендации по замене.
Вместо этого просто сначала установите Fink , MacPorts или Homebrew . Эти системы предоставляют систему управления пакетами, типичную для Linux или BSD. У каждого свой вкус и набор, поэтому правильный выбор будет зависеть от ваших вкусов и потребностей.
Вы можете обнаружить, что ни одна система пакетов не будет иметь все нужные вам программы. Некоторые программы еще не перенесены на OS X, поэтому они не будут отображаться ни в одной системе пакетов. Тем не менее, эти системы значительно расширяют возможности, поставляемые с OS X, и облегчат ваш переход с Linux.
Компиляторы командной строки OS X теперь по умолчанию создают 64-битные исполняемые файлы.
В Leopard и более ранних версиях компиляторы по умолчанию строили 32-битные исполняемые файлы. Это может вызвать проблемы по нескольким причинам: возможно, у вас есть старые 32-разрядные библиотеки, которые вы не можете восстановить, но на которые нужно ссылаться, возможно, вы все еще используете свою систему в 32-разрядном режиме и т. Д.
Один из способов заставить 32-битную сборку - это переопределить gccзначения по умолчанию в системах сборки gcc-4.0, которые являются старым 32-битным компилятором Leopard по умолчанию. ( 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 по умолчанию.
До Lion самое надежное место, где можно было найти подходящие инструменты для вашей системы, находилось на дисках ОС. Это необязательная установка.
Хорошая вещь об установке инструментов dev с дисков ОС состоит в том, что вы знаете, что инструменты будут работать с ОС. Apple, Apple, вам нужна последняя версия ОС для запуска новейших компиляторов, и они не всегда делают доступными загрузку старых инструментов, поэтому диски с ОС часто являются самым простым способом найти нужные инструменты для данной задачи. dev или test box.
С Lion они пытаются покончить с установочными носителями, поэтому, если вы не купите дорогую версию USB-ключа, вам придется скачать Xcode из App Store .
Я рекомендую вам сохранить хотя бы несколько версий загруженных вами DMG Xcode. Когда преемник Lion выйдет через год или три, вы можете оказаться без способа установить современную версию Xcode на тестовую виртуальную машину Lion. Планируйте заранее на случай, если проблемы доступности и нехватки носителей ОС сделают старые версии Xcode иначе недоступными.