2012-04-07 10 views
9

estoy tratando de recopilar algo que depende de GtkSpell, que depende de encantamiento, bajo MinGW. Recibo errores como gtkspell/gtkspell.c:757: undefined reference to '_imp__enchant_broker_init' Sospecho que esto se debe al hecho de que estoy tratando de vincular contra una biblioteca {estática, dinámica} cuando debería vincularme con el otro, o porque solo hay uno subrayado antes del PMI y debería haber dos; Consigo¿cómo lo arreglo referencia indefinida a _mej __ *?

$ objdump -t /d/opt/enchant-1.6.0/lib/libenchant.a | grep enchant_broker_init 
[ 85](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00002ac0 _enchant_broker_init 

y

$ objdump -t /d/opt/enchant-1.6.0/lib/libenchant.dll.a | grep enchant_broker_init 
[ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 _enchant_broker_init 
[ 7](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp__enchant_broker_init 

El Internet (http://lists.freedesktop.org/archives/gstreamer-devel/2007-January/013975.html) sugiere que el imp mangling proviene de

_declspec(dll{import,export}) 

aunque encantamiento parece utilizar

__declspec(dll{import,export}) 

, y comentando las líneas relevantes en enchant.h hace gtkspell.c solicitud enchant_broker_init en lugar de _imp__enchant_broker_init, pero no cambia los símbolos que aparecen en libenchant. ¿Hay una manera de hacer gcc no destrozar los nombres, o ¿alguien tiene ideas acerca de lo podría ir mal/cómo solucionarlo?

Aquí está un ejemplo mínimo que reproduce el problema en mi sistema:

Si tengo un archivo con contenido enchanttest1.c

#include <stdio.h> 
#include <enchant.h> 

int main() 
{ 
#ifdef ENCHANT_MODULE_EXPORT 
    printf("\nEnchant found\n"); 
#else 
    printf("\nEnchant not found\n"); 
#endif 
    return 0; 
} 

y una enchanttest2.c archivo con contenido

#include <stdio.h> 
#include <enchant.h> 

int main() 
{ 
    EnchantBroker *b = enchant_broker_init(); 
#ifdef ENCHANT_MODULE_EXPORT 
    printf("\nEnchant found\n"); 
#else 
    printf("\nEnchant not found\n"); 
#endif 
    return 0; 
} 

luego

gcc enchanttest1.c `pkg-config --cflags enchant` && ./a.exe 

da Enchant found pero

gcc enchanttest2.c `pkg-config --cflags enchant` && ./a.exe 

da

C:\Users\JASONG~1\AppData\Local\Temp\ccyDLptc.o:testenchant.c:(.text+0xf): undefined reference to `_imp__enchant_broker_init' 
collect2: ld returned 1 exit status 
+0

Esta es una sugerencia estúpida, pero ¿Se está asegurando que estás invocando C (no C++) compilación? ¿Puede estar experimentando un nombre sutil que arruina la ridiculez? –

+0

El 'encantar.archivo H' envuelve todo en '#ifdef __cplusplus extern "C"{ # endif' así que no creo que ese es el problema. También he agregado un ejemplo mínimo en el que estoy bastante seguro de estar invocando la compilación C. –

+0

Como nota para los seguidores, cuando obtuve esto fue porque la "biblioteca de dependencias" se definió con __declspec (dllimport), aunque era una compilación estática. Entonces, eliminando eso arreglado, mira http://betterlogic.com/roger/2012/09/libflite-cross-compile-woe/ – rogerdpack

Respuesta

5

La manera de arreglar mi mínima ejemplo es añadir --libs después --cflags; gcc no pudo encontrar la biblioteca para enlazar.

Pude solucionar el problema al que me estaba dirigiendo con el código más complicado que estaba intentando compilar (gummi (http://dev.midnightcoding.org/projects/gummi)) pasando LDFLAGS="$(pkg-config --cflags --libs gtkspell-2.0 enchant)" CFLAGS="$(pkg-config --cflags --libs gtkspell-2.0 enchant)" al script de configuración; el problema parece haber sido que los argumentos a gcc se aprobaron en el orden equivocado, y no pudo encontrar encantar cuando estaba tratando de vincular GtkSpell.