Xcode 6.1: файл был создан для x86_64, который не связан с архитектурой (i386)

Ответ 1

Удостоверьтесь, что у вас есть i386 и x86_64, перечисленные в настройках Архитектуры в сборке для вашей библиотеки. Также установите Только встроенная активная архитектура Нет.

Ответ 2

Я столкнулся с этой проблемой, и текущее решение избавилось от исходной ошибки (то есть не смог связать i386), но затем связанные фреймворки (такие как Alamofire) не могли быть импортированы в мой проект. Следующее решение исправило эту проблему.

1. В целевых Build Settings → Architectures → Valid Architectures добавьте значение i386.

2. Затем удалите содержимое папки с производными данными вашего проекта. Содержимое этой папки генерируется во время сборки и может быть безопасно удалено, а Xcode создаст новую. Чтобы удалить эту папку в Xcode 8, перейдите в File → Project/Workspace Settings, нажмите на серую стрелку, чтобы открыть местоположение папки в Finder, и удалите содержимое.

3. Очистить и восстановить.

4. Если сборка по-прежнему не удается, проверьте в навигаторе проблем что-то, что говорит Update to recommended settings. Нажмите на нее и попробуйте снова.
   Если вы не видите эту опцию, измените Build Active Architecture Only на Yes в настройках сборки. Это замедляет время сборки, что может разочаровать при частом переключении между различными устройствами, однако это может быть необходимо.

Ответ 3

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

1. Архитектура в iOS

armv64: iPhoneX, iPhone 5s-8, iPad Air - iPad Pro

armv7: iPhone3Gs-5c, iPad WIFI (4-го поколения)

armv6: iPhone - iPhone3G

выше, если для реальных устройств

i386: 32-битный симулятор

x86_64: 64-битный симулятор

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

больше информации об архитектурах iOS можно найти здесь: https://developer.apple.com/library/content/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/DeviceCompatibilityMatrix/DeviceCompatibilityMatrix.html

2. Что такое только активная архитектура?

Если выбрано "Да", ваша платформа будет построена только для "выбранного устройства", будь то реальные устройства (armv) или симулятор (x86_64 или i386). Для "Нет", это создаст вашу структуру к вашему списку "Действительных архитектур"

По умолчанию в режиме отладки это "Да"; и в выпуске more это "Нет", что может сэкономить время компиляции в режиме отладки и гарантировать, что инфраструктура проекта релиза работает на всех указанных вами архитектурах.

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

Таким образом, если вы работаете с фреймворком и хотите импортировать его в другой проект, если вы компилируете фреймворк с помощью Build Active Architecture Only "Да" с помощью симулятора (i386 или x86_64), а затем импортируете в свой проект с помощью Build Active Architecture Only "Да" с реальным устройством (armv), вы столкнулись с этой ошибкой.

Смотря на описание ошибки:

файл был создан для x86_64, который не является связываемой архитектурой (i386), подразумевает, что вы создадите свою платформу в 64-битном симуляторе, а ваш объединенный проект - с 32-битным симулятором.

в то время как более распространенным было бы:

Файл фреймворка был создан для x86_64, который не является связываемой архитектурой (arm64): это означает, что ваш фреймворк построен в симуляторе, в то время как ваш объединенный проект создается на реальном устройстве.

3. Извлечение основы

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

Две разные папки: Debug-iphoneos и Debug-iphonesimulator

Ответ 4

Я также обнаружил, что если вы используете фреймворки через cocoapods, как и я, мне приходилось идти на проект Pods и применять решения @dogsgod и @darksinge для каждой целевой среды в проекте Pods. То есть мне пришлось отключить сборку только для активных архитектур и добавить X86_64 и i386 в допустимые архитектуры.

Ответ 5

Обновление с React Native 57.8 до 58.4 привело к появлению этой проблемы с компоновщиком. Не было ошибки структуры, хотя. Вышеуказанные методы не работали, но для меня это исправило удаление раздела "Тест из целей" в xCode. Не нужно, так что это было хорошо для нас. Примером может служить проект с именем SuperCool, имеющий TARGETS: SuperCool, SuperCoolTests, SuperCool-tvOS и SuperCool-tvOSTests. Удалить SuperCoolTests, чтобы исправить.

Ответ 6

У меня была точно такая же ошибка по другой причине. Версия развертывания iOS для основного приложения была 10.0, и это было 11.0 на платформе. Поскольку 11.0 допускает только 64 бита, структура была скомпилирована только для 64 бит. И когда приложение хотело связать с платформой в 32 битах, у меня было это предупреждение:

file was built for arm64 which is not the architecture being linked (armv7)

Вслед за ошибкой компоновщика, конечно же, не найдено много символов из отсутствующего фреймворка.

Таким образом, изменение цели развертывания на iOS 10.0 на платформе исправило это. Изменение цели развертывания приложения на iOS 11.0, вероятно, также исправит это (генерируя только 64-битный двоичный файл).