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

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

• Ваш средний настольный Linux имеет более богатое пространство пользователя, чем тот из OS X.

  Вы, вероятно, пропустите различные инструменты, чем я сделал, таким образом, никакой смысл, определяющийся с рекомендациями для замен.

  Вместо этого просто установите Штрейкбрехера, MacPorts, или Домашнее пиво первая вещь. Эти системы обеспечивают систему управления пакета, типичную для Linux или BSDs. У каждого есть его собственная разновидность и набор пакета, таким образом, правильный выбор будет основан на Ваших вкусах и потребностях.

  Можно найти, что никакая система пакета не будет иметь каждую программу, в которой Вы нуждаетесь. Некоторые программы должны все же быть портированы к OS X, таким образом, они не появятся ни в какой системе пакета. Тем не менее, эти системы действительно значительно расширяют, какие поставки с OS X, и упростит Ваш переход от Linux.

• Компиляторы командной строки OS X теперь создают 64-разрядные исполняемые файлы по умолчанию.

  В Leopard и ранее, компиляторы создали 32-разрядные исполняемые файлы по умолчанию вместо этого. Это может вызвать проблемы несколькими способами: возможно, у Вас есть старые 32-разрядные библиотеки, которые Вы не можете восстановить, но иметь для соединения с, возможно, Вы все еще выполняете свою систему в 32-разрядном режиме и т.д.

  Один способ вызвать 32-разрядную сборку состоит в том, чтобы переопределить gcc значения по умолчанию в системах сборки с gcc-4.0, причем тот старый 32-bits-by-default компилятор Leopard. (gcc символьная ссылка на 64-bits-by-default 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. Они заботятся о niggly определенных для платформы различиях в схеме ссылки, таким образом, можно сохранить интеллектуальную мощь для изучения программ, Вы не можете абстрагировать далеко с портативными механизмами.

  Например, необходимо будет обновить память мышц, таким образом, Вы введете 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 базовая команда здесь. Если вместо этого Вы хотели установить библиотеку в a ../lib каталог относительно исполняемого файла, -id аргумент должен был бы быть @loader_path/../lib/libfoo.dylib вместо этого.

  Joe Di Pol написал хорошую статью об этом с намного большим количеством детали.

• Динамическая связь + сторонние пакеты может вызвать головные боли вначале.

  Вы, вероятно, столкнетесь с динамическими проблемами связи вначале, как только Вы начинаете пытаться пользоваться библиотеками от сторонних пакетов, которые не устанавливают библиотеки в стандартные местоположения. 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-разрядными версиями прочь в a 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 по умолчанию.

  Передо Львом самое надежное место для получения права dev инструменты для системы было на дисках ОС. Они - дополнительная установка.

  Хорошая вещь об установке dev инструментов от дисков ОС состоит в том, что Вы знаете, что инструменты будут работать с ОС. Так как Apple является Apple, у Вас должна быть последняя версия ОС для выполнения последних компиляторов, и они не всегда делали загрузки старых инструментов доступными, таким образом, диски ОС часто являются самым легким способом найти правильные инструменты для данного dev или тестового поля.

  Со Львом они пытаются покончить с медиа установки, поэтому если Вы не покупаете дорогую версию флеш-карты, необходимо будет загрузить XCode с App Store.

  Я рекомендую сохранить по крайней мере несколько версий любого DMGs XCode, который Вы загружаете. Когда преемник Льва выходит год или три следовательно, Вы могли бы оказаться без способа установить одновременную версию XCode на тестовом VM Льва. Запланируйте заранее в случае, если проблемы доступности и отсутствие медиа ОС делают старые версии XCode в других отношениях недоступными.