После перехода на OS X Mavericks и XCode 5.0.1 я больше не могу изящно связать скомпилированные файлы C (выходные данные gcc) с проектом C++ (выходные данные g++).
Оскорбительная пара команд, созданных из моего make-файла:
gcc `pkg-config --cflags glib-2.0` -g -Wall -O3 `pkg-config --cflags flann` -c -o vec.o vec.c
g++ `pkg-config --cflags glib-2.0` -g -Wall -O3 -stdlib=libstdc++ -lstdc++ layoutquality.cpp vec.o `pkg-config --libs glib-2.0` -L/usr/local/Cellar/flann/1.8.4/lib -lflann -o layoutquality
На что компоновщик жалуется:
Неопределенные символы для архитектуры x86_64: "load_dmat(char const*)", ссылка из: _main в layoutquality-I8HOqy.old: символ(ы) не найден(ы) для архитектуры x86_64
Где load_dmat
— это просто функция в файле vec.c. Если я заменю gcc
на g++
в первой строке, то все компилируется и линкуется нормально, но clang говорит:
clang: предупреждение: обработка ввода 'c' как 'c++' в режиме C++, такое поведение устарело
Есть ли безобидный, не устаревший способ их компиляции и связывания? Связывание с g++
вместе с объектными файлами из gcc
работало нормально, пока я не обновился до OS X Mavericks и новых инструментов командной строки. Любое понимание того, что изменилось и как двигаться вперед, было бы здорово, спасибо.
extern "C"
в объявленииload_dmat
, который скомпилирован в модуль C++? В противном случае компилятор C++ ожидает искаженное имя. - person nullptr   schedule 29.10.2013extern "C" { void load_dmat(char const*); }
. Используйте#ifdef __cplusplus
(как в ответе ниже), чтобы сохранить проекты C нетронутыми. - person nullptr   schedule 29.10.2013