Используя GNU Autoconf, автосделайте, и автозаголовок

Если Вы приносите существующую ранее утилиту командной строки к OS X, использующему GNU autoconf, automake, или autoheader, Вы, вероятно, найдете, что это конфигурирует себя без модификации (хотя получающаяся конфигурация может быть недостаточной). Просто выполненный configure и make поскольку Вы были бы в любой другой основанной на UNIX системе.

При выполнении configure сценарий перестал работать, потому что он не понимает архитектуру, попытайтесь заменить проект config.sub и config.guess файлы с доступными в /usr/share/automake-1.6. Если Вы распределяете приложения, использующие autoconf, необходимо включать актуальную версию config.sub и config.guess так, чтобы пользователи OS X не делали ничего дополнительного для разрабатывания проекта.

Если это все еще перестало работать, Вы, возможно, должны работать /usr/bin/autoconf на Вашем проекте восстановить configure сценарий, прежде чем это будет работать. OS X включает autoconf в пакет инструментов BSD. Вне этих основ, если проект не создает, Вы, возможно, должны изменить свой make-файл с помощью некоторых подсказок, предоставленных в следующих разделах. После того, как Вы сделаете это, более обширный рефакторинг может требоваться.

Некоторые программы могут использовать autoconf макросы, которые не поддерживаются версией autoconf, поставившего с OS X. Поскольку autoconf периодически изменяется, Вы, возможно, фактически должны получить новую версию autoconf, если необходимо создать очень последние источники для некоторых проектов. В целом большинство проектов включает предварительно созданный configure сценарий с выпусками, таким образом, это обычно не необходимо, если Вы не разрабатываете проект с открытым исходным кодом с помощью источников, полученных из CVS или из ежедневного исходного снимка.

Однако при нахождении необходимым обновить autoconf можно получить текущую версию от http://www .gnu.org/software/autoconf/. Обратите внимание на то, что autoconf, по умолчанию, устанавливает в /usr/local/, таким образом, Вы, возможно, должны изменить Ваш PATH переменная окружения для использования недавно обновленной версии. Не пытайтесь заменить версию, установленную в /usr/.

Для получения дополнительной информации об использовании автокомплекта инструментальных средств GNU посмотрите http://autotoolset .sourceforge.net/tutorial.html и страницы руководства autoconf, automake, и autoheader.

Компиляция для многократных архитектур ЦП

Поскольку платформа Macintosh включает больше чем одно семейство процессоров, часто важно скомпилировать программное обеспечение для многократных архитектур процессора. Например, библиотеки должны обычно компилироваться как универсальные двоичные файлы даже при монопольном предназначении для основанного на Intel компьютера Macintosh поскольку библиотекой может пользоваться двоичный файл PowerPC, работающий при Розетте. Для исполнимых программ, если Вы планируете распределить скомпилированные версии, необходимо обычно создавать универсальные двоичные файлы для удобства.

При компиляции программ для архитектуры кроме архитектуры узла по умолчанию, такой как компиляция для ppc64 или основанной на Intel цели Macintosh на основанном на PowerPC узле сборки, существует несколько типичных проблем, с которыми можно столкнуться. Большинство этих проблем следует из одной из следующих ошибок:

• Предположение, что узел сборки архитектурно подобен целевой архитектуре и таким образом будет способен к выполнению промежуточных продуктов сборки

• Попытка определить целевой процессор определенная информация во время конфигурации (путем компиляции и выполнения маленьких фрагментов кода), а не во время компиляции (использующий макро-тесты) или время выполнения (например, при помощи условного байта подкачивают функции),

Каждый раз, когда кросс-компиляция происходит, дополнительную заботу нужно соблюдать, чтобы гарантировать, что целевая архитектура обнаруживается правильно. Это - особенно проблема при генерации двоичного, содержащего объектный код больше чем для одной архитектуры.

Во многих случаях двоичные файлы, содержащие объектный код больше чем для одной архитектуры, могут быть сгенерированы просто путем выполнения нормального сценария конфигурации, затем переопределения флагов архитектуры во время компиляции.

Например, Вы могли бы работать

./configure

сопровождаемый

make CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc \

    -arch i386" LDFLAGS="-syslibroot /Developer/SDKs/MacOSX10.4u.sdk \

    -arch ppc -arch i386"

генерировать универсальный двоичный файл (для основанных на Intel и основанных на PowerPC компьютеров Macintosh). Для генерации универсального двоичного файла с 4 путями, включающего 64-разрядные версии Вы добавили бы -arch ppc64 и -arch x86_64 к CFLAGS и LDFLAGS.

Однако приложения, принимающие разовые конфигурацией решения относительно размера структур данных, обычно не создадут правильно в такой среде (так как те размеры, возможно, должны отличаться в зависимости от того, выполняет ли компилятор a ppc передача, a ppc64 передача, или i386 передача). Когда это происходит, инструмент должен быть сконфигурирован и скомпилирован для каждой архитектуры как отдельные исполнимые программы, затем склеил вручную использование lipo.

В редких случаях программное обеспечение, не записанное с кросс-компиляцией в памяти, сделает, конфигурируют разовые решения путем выполнения кода узла сборки. В этих случаях необходимо будет вручную изменить или сценарии конфигурации или получающиеся заголовки, чтобы быть подходящими для фактической целевой архитектуры (а не архитектура сборки). В некоторых случаях это может быть решено путем сообщения сконфигурировать сценарию, что Вы кросс-компилируете использование --host, --build, и --target флаги. Однако это может просто привести к значениям по умолчанию для вставляемой целевой платформы, который действительно не решает проблему.

Лучшая фиксация должна заменить, конфигурируют разовое обнаружение порядка байтов, размеров типа данных, и т.д. со временем компиляции или обнаружением во время выполнения. Например, вместо того, чтобы тестировать архитектуру на порядок байтов для получения непротиворечивого порядка байтов в файле необходимо выполнить одно из следующих действий:

• Используйте макросы препроцессора C как __BIG_ENDIAN__ и __LITTLE_ENDIAN__ протестировать порядок байтов во время компиляции.

• Используйте функции как htonl, htons, ntohl, и ntohs гарантировать представление с обратным порядком байтов на любой архитектуре.

• Извлеките отдельные байты поразрядным маскированием и смещением (например, lowbyte=word & 0xff; nextbyte = (word >> 8) & 0xff; и т.д.).

Точно так же вместо того, чтобы выполнить тщательно продуманные тесты, чтобы определить, использовать ли int или long для 4-байтовой части данных необходимо просто использовать тип стандартного размера такой как uint32_t.

Существует несколько других протестов при работе с универсальными двоичными файлами:

• Утилита архива библиотеки, ar, не может работать с библиотеками, содержащими код больше чем для одной архитектуры (или библиотеки единой архитектуры, сгенерированные с lipo) после того, как ranlib добавил оглавление к ним. Таким образом, если необходимо добавить дополнительные объектные файлы к библиотеке, необходимо сохранить отдельную копию без TOC.

• -M переключитесь на gcc (для вывода информации о зависимостях), не поддерживается, когда многократная архитектура указана на командной строке. В зависимости от Вашего make-файла это может потребовать существенных изменений к Вашим правилам make-файла. Поскольку находящиеся в autoconf конфигурируют сценарии, флаг --disable-dependency-tracking должен решить эту проблему.

  Для проектов использование автоделает, может быть необходимо работать, автоделают с -i флаг, чтобы отключить проверки зависимости или поместить no-dependencies в AUTOMAKE_OPTIONS переменная в каждом файле Makefile.am.

• При столкновении с проблемами, создающими универсальный двоичный файл для инструмента с открытым исходным кодом первая вещь, которую необходимо сделать, состоит в том, чтобы получить последнюю версию исходного кода. Это делает две вещи:

  • Гарантирует, чтобы версия autoconf и автосделала используемыми для генерации сценариев конфигурации, является довольно текущим, сокращая вероятность отказов сборки, отказов выполнения, назад или проблем прямой совместимости и другого особенного или прямого поврежденного поведения.

  • Сокращает вероятность создания версии инструмента с открытым исходным кодом, содержащего известные дыры в системе безопасности или другие серьезные ошибки.

• Более старые версии autoconf не обрабатывают случай где --target, --host, и --build не обрабатываются корректно. Различные версии также ведут себя по-другому при указании только одного или двух из этих флагов. Таким образом необходимо всегда указывать все три из этих опций, если Вы работаете, autoconf-сгенерированный конфигурируют сценарий с намерением кросс-скомпилировать.

• Некоторые более ранние версии дескриптора autoconf, кросс-компилирующего плохо. Если Ваш инструмент содержит сконфигурировать сценарий, сгенерированный ранним autoconf, можно быть в состоянии значительно улучшить вещи путем замены части из config.* файлы (и config.guess в частности) с обновленными копиями от версии autoconf, идущего с OS X.

  Это будет не всегда работать, однако, когда может быть необходимо фактически регенерировать сконфигурировать сценарий рабочей автоконференцией, Чтобы сделать это, просто измениться в корневой каталог проекта и работать /usr/bin/autoconf. Это будет автоматически обнаруживать и использовать configure.in файл и использование это для генерации нового конфигурирует сценарий. Если Вы получаете предупреждения, необходимо сначала попробовать веб-поиск сообщения об ошибке, поскольку кто-то еще, возможно, уже столкнулся с проблемой (возможно на различном инструменте) и нашел решение.

  Если Вы получаете ошибки о без вести пропавших AC_ макросы, Вы, возможно, должны загрузить копию библиотек, от которых Ваш инструмент зависит и копия их .m4 конфигурационные файлы autoconf в /usr/share/autoconf. Поочередно, можно добавить макросы к файлу acinclude.m4 в основном каталоге и autoconf Вашего проекта должен автоматически забрать тех макросы.

  Вы, возможно, в некоторых случаях, должны повторно выполниться automake и/или autoheader если Ваш инструмент использует их. Будьте подготовлены столкнуться с без вести пропавшими AM_ и AH_ макросы, если Вы делаете, как бы то ни было. Если выполнение autoconf отдельно не исправляет проблему сборки, из-за добавленного риска недостающих макросов это должно обычно только быть сделано.

• Различные make-файлы и конфигурируют переопределения командной строки дескриптора сценариев по-разному. Самый непротиворечивый способ вызвать эти переопределения состоит в том, чтобы указать их до команды. Например:

  make CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

  должен обычно приводить к вышеупомянутому, добавляемому к CFLAGS во время компиляции. Однако это поведение не является абсолютно непротиворечивым через make-файлы из различных проектов.

Для получения дополнительной информации о autoconf автосделайте, и автозаголовок, можно просмотреть autoconf документацию в http://www .gnu.org/software/autoconf/manual/index.html.

Поскольку дополнительная информация о компиляторе отмечает для основанных на Intel компьютеров Macintosh, изменяя код для поддержки CPUs с прямым порядком байтов и других проблем портирования, необходимо считать Универсальные Двоичные Инструкции по Программированию, Второй Выпуск, доступный от Ссылочной Библиотеки ADC.

Условная компиляция на OS X

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

Более старый код иногда использовал условные операторы как #ifdef __MACH__ или #ifdef __APPLE__ попытаться определить, компилировалось ли это на OS X или нет. В то время как это кажется обращением как быстрым способом быть портированным, оно в конечном счете вызывает больше работы в конечном счете. Например, при создании предположения, что определенная функция не существует в OS X и условно заменяет его собственной версией, реализующей ту же функциональность как обертка вокруг различного API, приложение больше может не компилировать или может быть менее эффективным, если Apple добавляет что функция в более поздней версии.

Кроме отображения или использования имени OS по некоторым причинам (который можно более переносимо получить из uname API), код никогда не должен вести себя по-другому на OS X просто, потому что это работает на OS X. Код должен вести себя по-другому, потому что OS X ведет себя по-другому в некотором роде — предложение дополнительной функции, не предложение функциональности, определенной для другой операционной системы, и т.д. Таким образом, для максимальной мобильности и пригодности для обслуживания, необходимо фокусироваться на том различии и сделать условную компиляцию зависящей от обнаружения различия, а не зависящий от OS самого. Это не только упрощает поддерживать Ваш код, как OS X развивается, но также и упрощает портировать Ваш код на другие платформы, которые могут поддерживать различные но перекрывающиеся наборы функций.

Наиболее распространенными причинами Вы могли бы хотеть использовать такие условные операторы, являются попытки обнаружить различия в:

• архитектура процессора

• порядок байтов

• чувствительность к регистру файловой системы

• другие свойства файловой системы

• компилятор, компоновщик или различия в наборе инструментальных средств

• доступность сред разработки приложения

• доступность заголовочных файлов

• поддержка функции или функции

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

Неправильное использование этих условных выражений часто вызывает проблемы. Например, если Вы предполагаете, что определенные платформы присутствуют, если те, которые определяются макросы, Вы могли бы получить отказы компиляции при создании 64-разрядной исполнимой программы. Если Вы вместо этого тестируете на доступность платформы, Вы могли бы быть в состоянии возвратиться к альтернативному механизму, такому как X11, или Вы могли бы пропустить создание графических частей приложения полностью.

Например, OS X обеспечивает макросы препроцессора для определения архитектуры ЦП и порядка байтов. Они включают:

• __i386__— (32-разрядный) Intel

• __x86_64__— (64-разрядный) Intel

• __ppc__— (32-разрядный) PowerPC

• __ppc64__— (64-разрядный) PowerPC

• __BIG_ENDIAN__— CPU с обратным порядком байтов

• __LITTLE_ENDIAN__— CPU с прямым порядком байтов

• __LP64__— LP64 (64-разрядная) модель данных

Кроме того, использование инструментов как autoconf, можно создать произвольную условную компиляцию на почти любой практической функции установки от тестирования, чтобы видеть, существует ли файл к наблюдению, если можно успешно скомпилировать часть кода.

Например, если часть Вашего проекта требует определенной среды разработки приложения, можно скомпилировать маленькую тестовую программу чей main вызовы функции функция в той платформе. Если тестовая программа компилирует и соединяется успешно, среда разработки приложения присутствует для указанной архитектуры ЦП.

Можно даже использовать этот метод, чтобы определить, включать ли обходные решения для известных ошибок в Apple или сторонних библиотеках и платформах, или путем тестирования версий тех платформ или путем обеспечения тестового сценария, воспроизводящего ошибку и проверку результатов.

Например, в OS X, poll не поддерживает файлы устройств такой как /dev/tty. Если Вы просто избегаете poll если Ваш код работает на OS X, Вы делаете два предположения, что Вы не должны делать:

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

• Вы предполагаете, что OS X является единственной платформой, не поддерживающей использование poll на файлах устройств. В то время как это - вероятно, истина для большинства файлов устройств, не вся поддержка файлов устройств poll во всех операционных системах, таким образом, это - также не обязательно допустимое предположение.

Лучшее решение состоит в том, чтобы использовать разовый конфигурацией тест, пытающийся использовать poll на файле устройств, и если вызов сбои, отключает использование poll. При использовании poll обеспечивает некоторое значительное преимущество, может быть лучше выполнить тест во время выполнения рано в Вашем выполнении приложений, затем использовать poll только если успешно выполняется тот тест. Путем тестирования на поддержку во время выполнения приложение может использовать poll API, если поддерживается определенной версией какой-либо операционной системы, отступая корректно, если она не поддерживается.

Хорошее правило состоит в том, чтобы всегда тестировать на самую определенную вещь, которая, как гарантируют, удовлетворит Ваши требования. Если Вы нуждаетесь в платформе, тестируете на платформу. Если Вы нуждаетесь в библиотеке, тестируете на библиотеку. Если Вы нуждаетесь в определенной версии компилятора, тестируете версию компилятора. И т.д. Путем выполнения этого Вы увеличиваете свои возможности, что Ваше приложение будет продолжать работать правильно без модификации в будущем.

Выбор компилятора

OS X поставляет два компилятора и их соответствующие наборы инструментальных средств. Компилятор по умолчанию основывается на GCC 4.2. Кроме того, компилятор на основе GCC 4.0 предоставлен. Более старые версии XCode также обеспечивают предыдущие версии. Компиляция для 64-разрядного PowerPC и основанных на Intel компьютеров Macintosh только поддерживается в версии 4.0 и позже. Компиляция 64-разрядных расширений ядра только поддерживается в версии 4.2 и позже.

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

Использование устаревшего GCC, набору инструментальных средств на основе 2.95.2 строго обескураживают, если Вы не должны поддерживать совместимость с версией 10.1 OS X.

Если Вы сталкиваетесь с проблемой, которая похожа на ошибку компилятора, попытайтесь использовать различную версию GCC. Можно выполнить различную версию путем установки CC переменная окружения в Вашем Make-файле. Например, CC=gcc-4.0 выбирает GCC 4.0. В XCode можно изменить параметр компилятора на основе на проект или основании на файл путем выбора различной версии компилятора в соответствующем инспекторе настроек сборки.

Установка флагов компилятора

Когда разрабатывание Ваших проектов в OS X, просто предоставление или изменение флагов компилятора нескольких ключевых опций являются всем, что необходимо сделать для портирования большинства программ. Они обычно указываются любым CFLAGS или LDFLAGS переменная в Вашем make-файле, в зависимости от которого часть цепочки компилятора интерпретирует флаги. Если не указано иное необходимо добавить эти флаги к CFLAGS в случае необходимости.

Некоторые общие флаги включают:

-flat_namespace (в LDFLAGS)

Изменения от двухуровневого до одноуровневого (плоского) пространства имен. По умолчанию OS X создает библиотеки и приложения с двухуровневым пространством имен, где ссылки на динамические библиотеки разрешены к определению в определенной динамической библиотеке, когда создается изображение. Использованию этого флага обычно обескураживают, но в некоторых случаях, неизбежно. Для получения дополнительной информации посмотрите Понимающие Двухуровневые Пространства имен.

-bundle (в LDFLAGS)

Производит Мужественный файл формата пакета, использующийся для создания загружаемых плагинов. Посмотрите ld страница справочника для большего количества обсуждения этого флага.

-bundle_loader исполнимая программа (в LDFLAGS)

Указывает, какая исполнимая программа загрузит плагин. Неопределенные символы в том пакете проверяются по указанной исполнимой программе, как будто это была другая динамическая библиотека, таким образом гарантируя, что пакет фактически будет загружаемым без отсутствующих символов.

-framework платформа (в LDFLAGS)

Соединяет исполнимую программу, создаваемую против перечисленной платформы. Например, Вы могли бы добавить - платформа vecLib для включения поддержки векторной математики.

-mmacosx-version-min версия

Указывает версию OS X, для которого Вы предназначаетесь. Необходимо предназначаться компиляции для самой старой версии OS X, на котором Вы хотите выполнить исполнимую программу. Кроме того, необходимо установить и использовать кросс-разработку SDK для той версии OS X. Для получения дополнительной информации посмотрите Руководство по совместимости SDK.

Примечание: OS X также использует это значение для определения поведения соответствия UNIX некоторого APIs. Для получения дополнительной информации читайте информацию о версии Unix 03 Соответствия.

Более обширное обсуждение для компилятора в целом может быть найдено в http://developer.apple.com/releasenotes/DeveloperTools/.

Понимание двухуровневых пространств имен

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

Двухуровневый проект пространства имен имеет много преимуществ для приложений Углерода. Однако это может вызвать проблемы для многих традиционных приложений UNIX, если они были разработаны для работы в плоской среде пространства имен.

Например, предположите одну библиотеку, вызовите ее libfoo, пользуется другой библиотекой, libbar, для его реализации функции barIt. Теперь предположите, что приложение хочет переопределить использование libbar со сжатой версией, вызванной libzbar. С тех пор libfoo был соединен против libbar во время компиляции это не возможно без перекомпиляции libfoo.

Позволить приложению переопределять ссылки, сделанные libfoo к libbar, Вы использовали бы флаг -flat_namespace. ld страница справочника имеет более детальное обсуждение этого флага.

Если Вы пишете библиотеки с нуля, это может быть достойно рассмотрения двухуровневая проблема пространства имен в Вашем проекте. Если Вы ожидаете, что кто-то может хотеть переопределить использование Вашей библиотекой другой библиотеки, у Вас могла бы быть подпрограмма инициализатора, берущая указатели на вторую библиотеку как ее параметры, и затем используйте те указатели для вызовов вместо того, чтобы вызвать вторую библиотеку непосредственно.

Поочередно, Вы могли бы использовать сменную архитектуру, в которой вызовы к внешней библиотеке выполняются от плагина, который мог быть легко заменен различным плагином для различной внешней библиотеки. Посмотрите Динамические Библиотеки и Плагины для получения дополнительной информации.

По большей части, однако, если Вы не разрабатываете библиотеку с нуля, это не практично для избегания использования -flat_namespace если необходимо переопределить ссылки библиотеки на другую библиотеку.

При компиляции исполнимой программы (в противоположность библиотеке), можно также использовать -force_flat_namespace сказать dyld использовать плоское пространство имен при загрузке любых динамических библиотек и пакетов, загруженных двоичным файлом. Это обычно не необходимо, как бы то ни было.

Формат исполняемых файлов

Единственный формат исполняемых файлов, который понимает ядро OS X, является Мужественным форматом. Некоторые инструменты образования моста предоставлены для классических форматов исполняемых файлов Macintosh, но Мужественный собственный формат. Это очень отличается от обычно используемой Исполнимой программы и Соединения Формата (ELF). Для получения дополнительной информации о Мужественном посмотрите OS X ABI Мужественная Ссылка Формата файла.

Динамические библиотеки и плагины

Динамические библиотеки и плагины ведут себя по-другому в OS X, чем в других операционных системах. Этот раздел объясняет некоторые из тех различий.

ld a.o b.o c.o ... -L/path/to/lib -lmytool

gcc -bundle a.o b.o c.o -o mybundle.bundle \

    -bundle_loader /Applications/MyApp.app/Contents/MacOS/MyApp

Пакеты

В файловой системе OS X некоторые каталоги хранят исполняемый код и программные ресурсы, связанные с тем кодом в одном дискретном пакете. Эти пакеты, известные как пакеты, прибывают в два варианта: комплекты приложений и платформы.

Существует два основных типа пакетов, что необходимо быть знакомы с во время основного процесса портирования: комплекты приложений и платформы. В частности необходимо знать, как использовать платформы, так как Вы, возможно, должны соединиться против содержания платформы при портировании приложения.

Обработка умножает определенные символы

Умножение определенной ошибки символа происходит, если существуют повторные определения для какого-либо символа в объектных файлах, которые Вы соединяете. Можно указать, что следующие флаги для изменения обработки умножают определенные символы при определенных обстоятельствах:

-multiply_defined treatment

Указывает, как умножаются, определенные символы в динамических библиотеках должны быть обработаны когда -twolevel_namespace имеет силу. Значения для обработки должны быть одним из:

• error— Обработка умножает определенные символы как ошибку.

• warning— Обработка умножает определенные символы как предупреждение.

• suppress— Проигнорируйте умножают определенные символы.

Поведение по умолчанию состоит в том, чтобы обработать, умножают определенные символы в динамических библиотеках как предупреждения когда -twolevel_namespace имеет силу.

-multiply_defined_unused treatment

Указывает, как неиспользованный умножаются, определенные символы в динамических библиотеках должны быть обработаны когда -twolevel_namespace имеет силу. Неиспользованное умножается, определенный символ является символом, определенным в выводе, также определяющемся в одной из динамических библиотек, но в который, но символ в динамической библиотеке не используется никакой ссылкой в выводе. Значения для обработки должны быть error, warning, или suppress. Значение по умолчанию для неиспользованного умножается, определенные символы должен подавить эти сообщения.

Предопределенные макросы

Следующие макросы предопределены в OS X:

__OBJC__

Когда Ваш код компилируется компилятором Objective C, этот макрос определяется. По умолчанию это происходит при компиляции a .m файл или любой заголовок включены a .m файл. Можно вынудить компилятор Objective C использоваться для a .c или .h файл путем передачи -ObjC или -ObjC++ флаги.

__cplusplus

Этот макрос определяется, когда Ваш код компилируется компилятором C++ (или явно или путем передачи -ObjC++ флаг).

__ASSEMBLER__

Этот макрос определяется при компиляции .s файлы.

__NATURAL_ALIGNMENT__

Этот макрос определяется в системах, использующих естественное выравнивание. При использовании естественного выравнивания, int выровненный на sizeof(int) граница, короткое целое выровненное на sizeof(short) граница, и т.д. Это определяется по умолчанию при компиляции кода для PowerPC architecutres. Когда Вы используете, это не определяется -malign-mac68k переключатель компилятора, и при этом это не определяется на архитектурах Intel.

__MACH__

Если системные вызовы Маха поддерживаются, этот макрос определяется.

__APPLE__

Этот макрос определяется в любом Компьютере Apple.

__APPLE_CC__

Этот макрос установлен в целое число, представляющее номер версии компилятора. Это позволяет Вам различить, например, между компиляторами на основе той же версии GCC, но с различными исправлениями ошибок или функциями. Большие значения обозначают более поздние компиляторы.

__BIG_ENDIAN__ и __LITTLE_ENDIAN__

Они, которые говорят макросы, использует ли текущая архитектура порядок байтов с обратным порядком байтов или с прямым порядком байтов. Для получения дополнительной информации посмотрите Компиляцию для Многократных архитектур ЦП.

Другие подсказки по портированию

В этом разделе описываются альтернативы определенному обычно используемому APIs.