2010-02-03 17 views
6

Tengo una biblioteca estática que he creado con MinGW, estoy intentando vincularla a esa biblioteca desde una aplicación Qt. Sigo recibiendo errores de enlazador causados ​​por uno de los archivos objeto en la biblioteca. Este archivo realmente declara un par de encabezados de Boost, uno para el uso de shared_ptr y el otro para que yo pueda hacer que una clase no se pueda copiar. Creo que usar esta funcionalidad de impulso es lo que está causando el problema, pero no tengo idea de por qué. Si hago un comentario sobre las clases en la aplicación Qt que usan la clase definida en el archivo, la aplicación Qt vincula bien. Esta es la parte de la salida de error:Referencias no definidas al intentar vincular la aplicación Qt con mi biblioteca estática

C: \ bla \ build \ windows \ MinGW \ libfoo.a (foo_ctis.cpp.obj):. Foo_ctis.cpp :(texto + 0x10a): indefinido referencia a `__gxx_personality_sj0'

C: \ bla \ build \ windows \ MinGW \ libfoo.a (foo_ctis.cpp.obj): foo_ctis.cpp :(texto + 0x12f):. referencia indefinida a ` _Unwind_SjLj_Register '

C: \ bla \ build \ windows \ MinGW \ libfoo.a (foo_ctis.cpp.obj):. foo_ctis.cpp :(texto + 0x203): referencia indefinida a `_Unwind_SjLj_Resume '

C: \ bla \ build \ windows \ MinGW \ libfoo.a (foo_ctis.cpp.obj):. Foo_ctis.cpp :(texto + 0x20e): referencia indefinida a ` _Unwind_SjLj_Unregister'

C: \ bla \ build \ windows \ MinGW \ libfoo.a (foo_ctis.cpp.obj): foo_ctis.cpp :(texto + 0x226):. referencia indefinida a `__gxx_personality_sj0'

C: \ blah \ build \ windows \ mingw \ libfoo.a (foo_ctis.cpp.obj): foo_ctis.cpp :(. text + 0x24b): referencia indefinida a `_Unwind_SjLj_Register '

C: \ bla \ build \ windows \ MinGW \ libfoo.a (foo_ctis.cpp.obj):. Foo_ctis.cpp :(texto + 0x31f): referencia indefinida a `_Unwind_SjLj_Resume'

C : \ bla \ build \ windows \ MinGW \ libfoo.a (foo_ctis.cpp.obj): foo_ctis.cpp :(texto + 0x32a):. referencia indefinida a `_Unwind_SjLj_Unregister'

C: \ bla \ build \ windows \ mingw \ libfoo.a (foo_ctis.cpp.obj): foo_ctis.cpp :(. text $ _ZN5boost6detail12shared_countC1IN3foo25foo_SomeClassImplEEEPT_ [boost :: detail :: shared_count :: shared_count (foo :: foo_SomeClassImpl *)] + 0xc): undefined referencia a `__gxx_personality_sj0'

C: \ bla \ build \ windows \ MinGW \ libfoo.a (foo_ctis.cpp.obj):. foo_ctis.cpp :(texto $ _ZN5boost6detail12shared_countC1IN3foo25foo_SomeClassImplEEEPT_ [detalle impulso :: :: shared_count: : shared_count (foo :: foo_SomeClassImpl *)] + 0x31): referencia indefinida a `_Unwind_SjLj_Register'

C: \ bla \ build \ windows \ MinGW \ libfoo.a (foo_ctis.cpp.obj): foo_ctis. CPP :(texto $ _ZN5boost6detail12shared_countC1IN3foo25foo_SomeClassImplEEEPT_ [detalle impulso :: :: :: shared_count shared_count (foo :: foo_SomeClassImpl *)] + 0xFB):. referencia indefinida a `_Unwind_SjLj_Resume'

C: \ blah \ build \ windows \ mingw \ libfoo.a (foo_ctis.cpp.obj): foo_ctis.cpp :(.$ _ZN5boost6detail12shared_countC1IN3foo25foo_SomeClassImplEEEPT_ texto [detalle impulso :: :: :: shared_count shared_count (foo :: foo_SomeClassImpl *)] + 0x106): referencia indefinida a `collect2 _Unwind_SjLj_Unregister': ld devuelto 1 código de salida

Otra Lo que hay que mencionar es que estoy usando un puntero a la implementación en esta clase. Cualquier ayuda sería muy apreciada.

Resuelto: Me di cuenta de que tenía una versión anterior de GCC en mi camino que se incluía antes de mi versión de GCC suministrada por MinGW. La versión anterior se incluyó en un paquete GNUStep que tenía desde hace un tiempo. Creo que la configuración de estas versiones diferentes estaba causando problemas. Gracias a Kemiisto, que estaba en el camino correcto para resolver el problema.

Respuesta

3

Parece que su biblioteca estática estaba vinculada a una distribución MinGW (es decir, tercera versión) pero intenta vincular su aplicación con esta biblioteca utilizando otra distribución MinGW (es decir, la cuarta versión que se distribuye con Qt binario). Debería reconstruir su biblioteca utilizando el mismo MinGW que utiliza para el desarrollo de su aplicación.

actualización

Puede ser que es otro problema bien conocido. Eche un vistazo al this topic. Es probable que tenga 2 carpetas diferentes con Qt libs

C:\Qt\2009.05\bin;C:\Qt\2009.05\qt\bin 

en su camino también. Bibliotecas en la primera carpeta (... \ bin) compiladas con VS2008 y bibliotecas en la segunda (... \ qt \ bin) compiladas con MinGW. Los elementos en la variable de ruta se buscan cuando se inicia su aplicación. De repente, la carpeta con bibliotecas "incorrectas" existe antes de la carpeta con el elemento correcto en su variable de ruta. Lo que puede hacer es copiar QtCore4.dll, QtGui4.dll y otras bibliotecas que necesita para la carpeta con su aplicación ejecutable. Espero que esto ayude.

Algunos enlaces sobre este problema:

+0

Hola kemiisto, gracias por tu respuesta. Creo que estoy usando la misma versión de MinGW. Estoy usando CMake para construir diferentes tipos de archivos make. Intenté construir makefiles para MinGW y recibía errores, así que incluí C: \ Qt \ 2009.05 \ mingw \ bin en mi ruta de comandos.Después de esto, CMake pudo generar los archivos make de MinGW y pude usar mingw32-make para construir la biblioteca estática. ¿No sería eso usar la misma versión? No creo tener otra versión en mi computadora. – csmithmaui

+0

@csmithmaui: en ese caso tengo una idea más. Agregué algo de información a mi mensaje. – Wildcat

+0

Analicé mi camino y de hecho no tengo ninguno de los que publicó anteriormente en él. Solo tengo C: \ Qt \ 2009.05 \ mingw \ bin. Mi biblioteca estática funciona bien en el símbolo del sistema después de incluir la ruta MinGW que acabo de mencionar. El problema es cuando trato de vincular a mi biblioteca desde QtCreator, obtengo los errores del enlazador. Leí los enlaces que publicaste, pero no creo que este sea mi problema. Además, si elimino cualquier referencia a la clase contenida en el archivo en cuestión, todo lo demás se relaciona bien. Realmente aprecio tu ayuda. – csmithmaui

2

Sólo en caso de que alguien más tiene este problema: mi proyecto de reconstrucción se .o usando archivos de una construcción anterior. Cambié los compiladores en el medio.

Resulta que cuando reconstruí el mismo proyecto, el nuevo compilador no compiló nuevos archivos .o, por lo que les faltaba información clave. Después de eliminar los archivos viejos y reconstruir, se corrigió el error.

Supongo que la reconstrucción desde cero, sin la eliminación, funcionaría igual.

0

puede haber usado gcc en lugar de g++. gcc es un compilador de C pero g ++ es un compilador de C++.

solo asegúrate de usar g ++ si tienes archivos .cpp.

Cuestiones relacionadas