Успешная сборка Xcode 4, сборка командной строки завершается с ошибкой?

Ответ 1

Хорошо, так что почти 6 (оплачиваемых) часов спустя, я получил правильную работу сборки в Xcode и в командной строке (и на сервере сборки - все это упражнение).

По пути я бы исправил одну проблему только для того, чтобы вызвать другую - я бы, по-видимому, исправил проблему компоновщика /Ld, только чтобы вызвать проблемы в компиляции ( "SomeClass uneclared (сначала использовать в этой функции)" или "SomeHeader.h: Ошибок такого файла или каталога не было.)

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

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

• Преобразованная сборка для использования рабочего пространства и схемы Xcode (вместо проекта и цели).
• Перестроенное рабочее пространство, чтобы проект приложения и статическая библиотека были родными (не как родительские/дочерние).
• Изменены параметры Xcode и рабочей области для использования мест размещения, указанных в целевых объектах.
• Изменить путь к продуктам для приложения и библиотеки для использования. /build (оба файла проекта содержатся в подпапках sibling основного каталога, поэтому, если они встраиваются в одну папку, решаются исходные проблемы с компоновщиком /Ld, я думаю )
• Отредактирована схема приложения для явного создания цели библиотеки и ее создания до назначения приложения
• На этапе построения фаз для приложения явным образом добавьте библиотеку в разделе "Связывание с библиотеками"
• Измените тип местоположения библиотеки. Ссылка на файл "Относительно сборки продуктов"
• Добавлена ​​фаза сборки "Копирование заголовков" в проект "Библиотека", добавлены соответствующие заголовки в раздел "Общие".
• Изменен путь папки общих заголовков библиотеки проекта к "/include"
• Изменен каталог установки библиотеки $(BUILT_PRODUCTS_DIR)
• Изменены пути поиска библиотеки и пути поиска заголовка пользователя целевой точки приложения к $(BUILT_PRODUCTS_DIR) (рекурсивный)
• Добавлена ​​команда Clean перед сборкой на моем сервере сборки Jenkins.
• Добавлены явные аргументы SDK и Arch в команду сборки
• Удаленные пробелы из имени конфигурации сборки

Команда Final build выглядит следующим образом:

xcodebuild -workspace ClientName.xcworkspace -scheme AppName -configuration "ProdAdHoc" -sdk iphoneos -arch "armv6 armv7"

Некоторые полезные ресурсы, которые я использовал при отладке этой проблемы:

• http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4/
• https://devforums.apple.com/thread/91711?start=25&tstart=0

В любом случае, я надеюсь, что я набрал достаточное количество ключевых слов, чтобы кто-нибудь, у кого есть подобные проблемы сборки, в будущем натыкается на это и считает его полезным. Я не знаю, как много раз я делал много раз в Xcode 3.x, когда перешел на Xcode 4, надеясь, что Apple сможет очистить его в будущих выпусках.

Это было чертову опыта обучения для меня, и, проходя через все это, похоже, я выяснял проблемы с автозаполнением, которое я имел заранее. Я скажу, что все могло быть намного хуже; Я все еще мог развиваться для SharePoint.

Ответ 2

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

Использование рабочей области/схемы вынуждает xcodebuild использовать папку DerivedData вместо папки вывода сборки в основном проекте. Это позволило компоновщику найти связанную статическую библиотеку.

Это сообщение в блоге было чрезвычайно полезно:

http://blog.carbonfive.com/2011/05/04/automated-ad-hoc-builds-using-xcode-4/

Ответ 3

Я получил эту ошибку, когда экспериментировал с моими файлами. Я добавляю @implementation в файл .h и оставляю файл .m пустым. Я не верю, что это ваша ошибка, но если кто-то еще получит ее, возможно, проверьте, что вы этого не сделали.

Ответ 4

Проверьте, не импортировали ли файлы .m в файлы заголовков! Изменение .m на .h исправило это для меня!

Ответ 5

Я не знаю, будет ли это работать для вас, но в моем случае у меня было более одного файла main.m. Все, что мне нужно было сделать, это отсоединить один из main.m от цели, и это сработало. Убедитесь, что в вашем проекте не более одного main.m.

Ответ 6

Если вы посмотрите на журнал сборки, попросив увидеть все сообщения, вы должны увидеть краткую строку с надписью "link...", которая мало что может описать. Однако, если вы щелкните правой кнопкой мыши по этой строке и выберите "expand all transcripts", вы получите очень подробную строку, рассказывающую вам, какая команда была выпущена из XCode.

Это должно помочь вам отладить проблему.

Dave

Ответ 7

У меня возникло подобное исключение, оказалось, что я получил некоторую (нулевую) ссылку в project.pbxproj после того, как я очистил эту нулевую ссылку в проекте project.pbxproj, сборка командной строки была успешной, как и ранее выполнял xcode. Взгляните на проект Xcode 4: утилита для очистки файла pbxproj? утилита к очистке повышающего pbxproj файл

для дополнительной справки

Ответ 8

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

linker command failed with exit code 1 (use -v to see invocation)

... но это оказалось очень легко исправить, не нужна командная строка!

Я нажал на свой корень проекта (тот, что сверху с иконкой чертежа с "A" ) в Навигаторе, затем щелкнул раздел PROJECT (вы также можете нажать раздел TARGET), а затем щелкнуть по кнопке в нижней части под названием "Подтвердить настройки".

XCode сам подтвердил файлы проекта и сказал мне, что проблема была дублированным целевым определением и предложила исправить ее... и voilá, проблема в ее исчезновении!

Удачи!

Ответ 9

Я разрешаю проблему, перейдя в "путь поиска библиотеки" и убедитесь, что все записи верны.

Ответ 10

Лично у меня была эта проблема, когда я разрабатывал static library. У меня была цель static library со всем производственным кодом и тестовой целью, которая вытащила файл MyStaticLib.a в качестве рамки.

Тесты выполнялись отлично в Xcode, но не в терминале, используя xcodebuild. Проблема заключалась в том, что цель static library составляла компиляцию для Standard architectures, в то время как целевая аудитория хотела скомпилировать для Standard architectures (including 64-bit). Переключение тестовой цели на Standard architectures исправлено.