Objective-C / C ++ - ошибка компоновщика / метод Подпись проблема

Question

Есть статический класс Pipe, определенный в заголовке C ++, который я включаю.

Статический метод, который я заинтересован в вызове (из Objective-c), находится здесь:

static ERC  SendUserGet(const UserId &_idUser,const GUID &_idStyle,const ZoneId &_idZone,const char *_pszMsg);

У меня есть доступ к структуре данныхjective-c, которая, кажется, хранит копию userID и zoneID - это выглядит так:

@interface DataBlock : NSObject
{
    GUID userID;
    GUID zoneID;
}

Посмотрел определение GUID, и это структура с кучей перегруженных операторов на равенство. UserId и ZoneId из первой сигнатуры функции: #typedef GUID

Теперь, когда я пытаюсь вызвать метод, независимо от того, как я его приведу (const UserId), (UserId) и т. Д., Я получаю следующую ошибку компоновщика:

Ld build/Debug/Seeker.app/Contents/MacOS/Seeker normal i386
cd /Users/josh/Development/project/Mac/Seeker
setenv MACOSX_DEPLOYMENT_TARGET 10.5
/Developer/usr/bin/g++-4.2 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -L/Users/josh/Development/TS/Mac/Seeker/build/Debug -L/Users/josh/Development/TS/Mac/Seeker/../../../debug -L/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/gcc/i686-apple-darwin10/4.2.1 -F/Users/josh/Development/TS/Mac/Seeker/build/Debug -filelist /Users/josh/Development/TS/Mac/Seeker/build/Seeker.build/Debug/Seeker.build/Objects-normal/i386/Seeker.LinkFileList -mmacosx-version-min=10.5 -framework Cocoa -framework WebKit -lSAPI -lSPL -o /Users/josh/Development/TS/Mac/Seeker/build/Debug/Seeker.app/Contents/MacOS/Seeker

Undefined symbols:
  "SocPipe::SendUserGet(_GUID const&, _GUID const&, _GUID const&, char const*)", referenced from:
  -[PeoplePaneController clickGet:] in PeoplePaneController.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Это ошибка подписи типа / функции или действительно какая-то ошибка компоновщика? У меня есть заголовки, в которых все эти типы и статические классы определены #imported - я тоже на всякий случай пробовал #include, так как я уже спотыкаюсь: P

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

Редактировать: добавлен полный текст ошибки компоновщика. Изменили «функцию» на «метод». Также я отмечу, что мы используем собственный make-файл для компиляции нескольких внешних проектов. Однако в этом проекте xcode статические методы SocPipe упоминаются в другом месте и, похоже, прекрасно компилируются.

Answer 1

Объектный файл, содержащий Pipe::SendUserGet, не создается или не связан с вашей целью XCode. Правильно ли работают другие статические методы в Pipe, не обязательно, если эти методы определены в заголовочном файле.

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

Например, если у вас есть make-файл, который создает libLIBRARY.a, затем перетащите libLIBRARY.a в свой проект и добавьте его к своей цели.

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

Answer 2

(Эх, давайте превратим этот комментарий в ответ.)

Подпись метода выглядит отлично; то, что вы называете, соответствует тому, что объявлено в заголовке. Если это не так, вы, вероятно, получите ошибку компиляции, а не ошибку компоновщика.

Проблема компоновщика заключается в том, что у него нет соответствующего объектного кода для подключения этого вызова: метод объявлен , но никогда определен .

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