Pregunta

Tengo un archivo de prueba simple, TestMe.cpp:

#include <gtest/gtest.h>

TEST(MyTest, SomeTest) {
  EXPECT_EQ(1, 1);
}

int main(int argc, char **argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

Tengo Google prueba construido como una biblioteca estática. (Puedo proporcionar el makefile si es relevante).

Me puede compilar TestMe.cpp desde una línea de comandos sin ningún problema:

g++ TestMe.cpp -IC:\gtest-1.5.0\gtest-1.5.0\include -L../gtest/staticlib -lgtest -o TestMe.exe

Se ejecuta como se esperaba.

Sin embargo, no puedo conseguir esto para compilar en Qt. Mi archivo de proyecto Qt, en el mismo directorio:

SOURCES += TestMe.cpp
INCLUDEPATH += C:\gtest-1.5.0\gtest-1.5.0\include
LIBS += -L../gtest/staticlib -lgtest

Estos resultados en 17 errores "símbolo externo sin resolver" relacionados con funciones GTEST.

Estoy tirando de mi pelo que aquí, como estoy seguro de que es algo sencillo. Algunas ideas?

Éstos son algunos de los símbolos externos que están definido:

TestMe.obj:-1: error:  unresolved external symbol "public: int __thiscall testing::UnitTest::Run(void)" (?Run@UnitTest@testing@@QAEHXZ) referenced in function _main
TestMe.obj:-1: error:  unresolved external symbol "public: static class testing::UnitTest * __cdecl testing::UnitTest::GetInstance(void)" (?GetInstance@UnitTest@testing@@SAPAV12@XZ) referenced in function _main
TestMe.obj:-1: error:  unresolved external symbol "void __cdecl testing::InitGoogleTest(int *,char * *)" (?InitGoogleTest@testing@@YAXPAHPAPAD@Z) referenced in function _main
TestMe.obj:-1: error:  unresolved external symbol "public: __thiscall testing::internal::AssertHelper::~AssertHelper(void)" (??1AssertHelper@internal@testing@@QAE@XZ) referenced in function "private: virtual void __thiscall MyTest_SomeTest_Test::TestBody(void)" (?TestBody@MyTest_SomeTest_Test@@EAEXXZ)
¿Fue útil?

Solución

Nunca podría conseguir que esto funcione como una biblioteca estática, sino que está funcionando como un archivo DLL.

En primer lugar, tenía que construir Google prueba como un archivo DLL. No he tenido ningún éxito conseguir que esto funcione en Visual Studio, por lo que acabo de utilizar mingw32-make. Se puede utilizar el Makefile proporciona en la fuente, realizando los cambios siguientes:

gtest-all.o : $(GTEST_SRCS_)
    $(CXX) $(CPPFLAGS) -DGTEST_CREATE_SHARED_LIBRARY=1 -I$(GTEST_DIR) $(CXXFLAGS) -c \
            $(GTEST_DIR)/src/gtest-all.cc

gtest_main.o : $(GTEST_SRCS_)
    $(CXX) $(CPPFLAGS) -DGTEST_CREATE_SHARED_LIBRARY=1 -I$(GTEST_DIR) $(CXXFLAGS) -c \
            $(GTEST_DIR)/src/gtest_main.cc

gtest.dll : gtest-all.o
    $(CXX) -shared -o $@ $^ -Wl,--out-implib,gtest_dll.lib

gtest_main.dll : gtest-all.o gtest_main.o
    $(CXX) -shared -o $@ $^ -Wl,--out-implib,gtest_main_dll.lib

A continuación, cuando se compila el proyecto de prueba, debe:

  • Definir GTEST_LINKED_AS_SHARED_LIBRARY = 1
  • Establecer una referencia a la biblioteca ya sea gtest_dll.lib o gtest_main_dll.lib.
  • Pegar gtest.dll o gtest_main.dll en el mismo directorio que el ejecutable.

(Mi entendimiento es que utilice gtest_main sólo si usted no está proporcionando a su propia función main ().)

A continuación se muestra un archivo de pro Qt basado en el que tengo esto está funcionando (por fin!):

DEFINES += GTEST_LINKED_AS_SHARED_LIBRARY=1
SOURCES += main.cpp MyClassTests.cpp
INCLUDEPATH += ../path/to/gtest/includes
LIBS += -L../path/to/gtest/libraries -lgtest_dll \
    -L../ClassLibrary/bin -lMyClass
CONFIG += console

Otros consejos

Estoy usando Qt + GTEST / gmock sin ningún problema. Yo sólo he probado todas las combinaciones posibles de rutas absolutas / relativas con diferentes barras, pero no podía reproducir el problema. ¿Ha comprobado el contenido de "LIBS" variable a partir de Makefile.Debug generada por qmake?

Aquí hay alguna pieza genérica de consejo: no utilice rutas absolutas, porque su código no se compilará en otras máquinas de su cuenta, a menos que usted lo descargue en exacly misma ubicación (que podría no ser posible debido a Qt configuración diferente, etc.). Utilizar rutas relativas en cambio, también en las librerías de 3 ª parte.

Me mantener las bibliotecas 3 ª parte en el sistema de control de versiones (se utiliza uno, ¿verdad?). Tengo un directorio "3rdparty" y para cada proyecto que utiliza las librerías, agrego propiedad svn: señalización externo a la versión especificada explícitamente de tercera parte lib. La última parte es importante, ya que garantiza que usted será capaz de construir cada revisión de su proyecto, incluso cuando se actualiza la biblioteca tercera parte.

creo que está bien para su archivo qmake. Pero ¿Por qué es INCLUDEPATH absoluta y relativa LIBS. Me gustaría probar la configuración absoluta LIBS también.

A partir de aquí http://doc.trolltech.com/4.6/qmake-variable- reference.html # includepath

Pero ¿cuál es el problema principal (creo) que necesita para poner barras diagonales en INCLUDEPATH. En la documentación que es así.

INCLUDEPATH += C:/gtest-1.5.0/gtest-1.5.0/include
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top