Apple, Mach-O Linker Error, из-за расширения имени файла

Страшный типичная ошибка линкера ..Apple, Mach-O Linker Error, из-за расширения имени файла

л.д.: символ (ы) не найдено для архитектуры ARMv6 collect2: л.д. возвращается Статус 1 Выход из

Однако, это вызвано именем файла? Я использую C++/Objective-C, поэтому все мои файлы Obj-C - .mm, но я никогда не могу использовать какие-либо файлы .c. Например, я включил алгоритм SFMT в свой проект, который давал мне эти ошибки, но просто изменение одного файла .c на .cpp заставило его уйти, а код работает просто отлично! Я включаю только заголовки, поэтому я не уверен, почему это имеет значение.

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

Любая идея, почему это произойдет? Как я могу остановить ошибки компоновщика для .c файлов?

источник

2012-02-12 user1137704

Как вы создаете двоичный код для Freetype? Я уверен, что вы уже знаете это, но вы не можете просто libfreetype.a скомпилированы для настольной платформы. –

После этого урока я построил двоичный код для всех 4 архитектур и объединил их в несвободный freetype.a. Я попробую еще раз, так как я получаю ту же ошибку, что и в iOS Simulator. Так что не только я не хватаю руки6/7. – user1137704

Вы забыли опубликовать ссылку на учебник. Я использую метод, описанный здесь (http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4/) при использовании сторонних библиотек. Единственная проблема, с которой я сталкиваюсь в этом методе, заключается в том, что когда я что-то меняю в библиотеке, приложение не переписывается с обновленной библиотекой, если только я не очищаю сначала. –

Оберните ваш Freetype включает в пределах extern "C" директивы:

// Non-C includes 
#include <iostream> 

extern "C" 
{ 
    #include <freetype/freetype.h> 
    // ... Other freetype includes 
}

Вы можете, вероятно, использовать #import вместо #include в пределах extern "C" директивы. Я никогда не пробовал, но я не понимаю, почему это не сработает.

источник

2012-02-12 07:38:34

Полезно знать. Это решило мою проблему с SFMT, но Freetype все еще жалуется, поэтому, возможно, что-то не так с бинарником или связью, мне придется больше изучить его. Спасибо за быстрые ответы! – user1137704

Окружайте свой заголовочный файл c этим. Это также может включать в себя:

#ifdef __cplusplus 
extern "C" {   
#endif  

// function declarations etc if this is your own header. 
// OR you can use this in the .mm file to surround your include. 
//... 

#ifdef __cplusplus  
};      
#endif

Это указывает внешнюю связь для ваших функций c. Если вы не делаете этого, когда включаете свои файлы c .h, компилятор C++ будет калечить иначе, чем компилятор C, и вызывать проблемы для компоновщика.
Используя extern "C", вы сообщаете своему компилятору C++ использовать функции C-стиля для функций.

источник

2012-02-12 07:36:16

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

Хороший момент - я впервые пропустил, что OP включал стороннюю библиотеку.Если это его собственный код, он может предпочесть использовать спецификацию привязки в заголовке (поэтому ему не нужно делать это при каждом включении). Я изменил свой ответ, включив ваше предложение. –

Apple, Mach-O Linker Error, из-за расширения имени файла

ответ

Смежные вопросы