Странное поведение при компиляции тестов CppUTest для приложения с использованием Qt и Boost
У меня следующая проблема. Когда я пытаюсь скомпилировать библиотеку .so, все работает нормально.
Scanning dependencies of target logger
[ 11%] Building CXX object CMakeFiles/logger.dir/src/defaultconfig.cpp.o
[ 22%] Building CXX object CMakeFiles/logger.dir/src/loggerstate.cpp.o
[ 33%] Building CXX object CMakeFiles/logger.dir/src/configmanager.cpp.o
[ 44%] Building CXX object CMakeFiles/logger.dir/src/configuration.cpp.o
[ 55%] Building CXX object CMakeFiles/logger.dir/src/formatter.cpp.o
[ 66%] Building CXX object CMakeFiles/logger.dir/src/levelmap.cpp.o
[ 77%] Building CXX object CMakeFiles/logger.dir/src/logger.cpp.o
[ 88%] Building CXX object CMakeFiles/logger.dir/src/logworker.cpp.o
[100%] Linking CXX shared library liblogger.so
[100%] Built target logger
Когда я пытаюсь создать исполняемый файл, который использует, например, logger.cpp например. Тестовый файл Я получаю стену ошибок. Полный лог здесь. Однако самое забавное, что он компилируется на компьютере разработчика. Мы проверяем версию компилятора, версию cmake и все так же. Cpputest версия не была той же.
Может быть, кто-то из вас сталкивался с такой проблемой и знает, что мы делаем не так.
Решение
In file included from /opt/Qt5.3.2/5.3/gcc_64/include/QtCore/qobject.h:51:0,
from /opt/Qt5.3.2/5.3/gcc_64/include/QtCore/qabstractanimation.h:45,
from /opt/Qt5.3.2/5.3/gcc_64/include/QtCore/QtCore:4,
from /opt/Qt5.3.2/5.3/gcc_64/include/QtConcurrent/QtConcurrentDepends:2,
from /opt/Qt5.3.2/5.3/gcc_64/include/QtConcurrent/QtConcurrent:3,
from /tmp/Quantum/src/logger/include/logworker.h:5,
from /tmp/Quantum/src/logger/include/logger.h:5,
from /tmp/Quantum/src/logger/tests/logger_test.cpp:5:
/opt/Qt5.3.2/5.3/gcc_64/include/QtCore/qlist.h: In member function ‘void QList<T>::node_construct(QList<T>::Node*, const T&)’:
/opt/Qt5.3.2/5.3/gcc_64/include/QtCore/qlist.h:374:44: error: ‘n’ does not name a type
else if (QTypeInfo<T>::isComplex) new (n) T(t);
^
Ошибка выглядит как <new> заголовок не был включен. Убедитесь, что в путях включения нет другого файла с именем «new», и убедитесь, что другие заголовки не определяют макрос, такой как _NEW или же _LIBCPP_NEW что помешает <new> от включения правильно.
Вам может понадобиться скомпилировать один из сбойных файлов с таким флагом, как -save-temps Таким образом, вы можете просмотреть предварительно обработанный вывод, чтобы увидеть, какие файлы включены, и если их содержимое включено.
Вы также должны указать CMake быть многословным, чтобы он печатал полные команды компилятора. Бесполезно скрывать детали компиляции, если компиляция терпит неудачу — вам нужно знать, что происходит!
Другие решения
Наконец мы победили эту проблему. Проблема здесь заключалась в том, что, как предполагают @Jonathan Wakely, cpputest определяет макрос _NEW которые мешают new от включения правильно. Чтобы решить эту проблему, мы переупорядочиваем включаемые файлы, чтобы включить все библиотеки перед включением cpputest заголовки.