Разработчик программного обеспечения переключается с Linux на OS X, что за ошибки?

Я использовал Ubuntu / Fedora / Red Hat / Suse, но не использовал OS X вообще. Если мне придется регулярно использовать OS X, на что мне стоит обратить внимание?

Инструменты, которые я использую - это цепочка инструментов GNU, C ++ / Boost и т. Д.

Я сделал то же самое несколько лет назад. Вот вещи, с которыми я столкнулся:

• Ваш обычный настольный 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 иначе недоступными.

ОГРОМНОЕ GOTCHA - файловая система Mac OS НЕ чувствительна к регистру.

Хотя Fink и MacPorts являются традиционными средствами получения пакетов Unix для OS X, я бы порекомендовал проверить новый инструмент под названием brew, который работал лучше для меня и меньше мешал с моей системой, и его намного проще использовать. Он просто загружает tar-архивы и устанавливает их в / usr / local, но он очень хорошо автоматизирует весь процесс.

http://mxcl.github.com/homebrew/

ОГРОМНОЕ GOTCHA - файловая система Mac OS НЕ чувствительна к регистру.

Вы можете создать чувствительный к регистру образ диска в Mac OS X, который можно подключить как обычный том жесткого диска.

# cf. http://codesnippets.joyent.com/posts/show/8617
IMAGE="${HOME}/Desktop/Case Sensitive Test.dmg"
VOLNAME="Case Sensitive Test"

hdiutil create "${IMAGE}" -size 10m -fs HFSX -volname "${VOLNAME}" -layout NONE

hdiutil attach "${IMAGE}"

cd "/Volumes/${VOLNAME}"
touch foo.txt Foo.txt
open .
ls -l [Ff]oo.txt
stat -f "inode: %i  --  name: %N" [Ff]oo.txt

cd ~
hdiutil detach "/Volumes/${VOLNAME}"

Вот хороший источник избранных статей для разработчиков, Список литературы по Какао:

http://osx.hyperjeff.net/Reference/CocoaArticles

(Это может быть особенно полезно, если однажды вы захотите воспользоваться специфическими вкусностями Mac OS X.)

При переносе сетевого стека из Solaris, BSD, Linux и Windows в OSX единственное главное, на что обращает внимание, это то, что, как и во FreeBSD, вся цепочка инструментов довольно старая.

Apple работает с OSX Lion, но Leopard и Snow Leopard отстают от современных дистрибутивов Linux, и многие стандарты не поддерживаются. В моем случае я столкнулся с отсутствием RFC 3678 (расширения интерфейса сокета для многоадресных исходных фильтров), что было довольно неудобно.

На сервере OSX я установил чувствительную к регистру файловую систему, поскольку она рекомендует делать это для обслуживания HTTP.

• Старый GCC
• Старый Autoconf, Automake, libtool
• Нет спин-блокировки Pthread, OSX предоставляет нативные альтернативы.
• Немногие API-интерфейсы NSS с повторной арендой.
• Не слишком полезная /procфайловая система.
• Нет /dev/rtc, /dev/hpetи, RDTSCкажется, навязчиво. OSX предоставляет нативные альтернативы.
• Нет epoll, но у вас есть pollи kqueue

OS X поддерживает, pthread_cond_timedwaitно использует абсолютное календарное время, и нет возможности использовать монотонно увеличивающееся время.