GCC Sin vincular las bibliotecas correctas

Tengo instaladas dos versiones de GCC en mi sistema 4.6.2 y 4.7.0. Estoy ejecutando Fedora Core 16.GCC Sin vincular las bibliotecas correctas

4.6.2 está instalado en /usr/bin y 4.7.0 está instalado en /home/nerozehl/local/bin. Las bibliotecas y el tiempo de ejecución para C++ también se compilan e instalan en /home/nerozehl/local/lib y /home/nerozehl/local/lib64.

También tengo instaladas dos versiones de Boost, con bibliotecas en /usr/lib64 y /home/nerozehl/local/lib. (Boost 1.47.0 y 1.49.0, respectivamente)

El problema que estoy teniendo es que g ++/ld están vinculando con las bibliotecas predeterminadas, y no las más nuevas en /home/nerozehl/local. Estoy usando configure para generar Makefiles, y estoy llamando de esta manera:

CXX=g++47 CXXFLAGS="-g -O0 -pg" LDFLAGS="-L/home/nerozehl/local/lib" ./configure --prefix=/home/nerozehl/local

Dónde g++47 reside en el /home/nerozehl/local/bin (en mi $PATH).

Cuando compilo, todo está bien, y se utilizan los encabezados más recientes, pero cuando puedo comprobar lo que estaba vinculada en contra:

ldd source/noes 
    linux-vdso.so.1 => (0x00007fffebfff000) 
    libboost_filesystem-mt.so.1.47.0 => /usr/lib64/libboost_filesystem-mt.so.1.47.0 (0x0000003c6a800000) 
    libboost_system-mt.so.1.47.0 => /usr/lib64/libboost_system-mt.so.1.47.0 (0x0000003c6a400000) 
    libboost_program_options-mt.so.1.47.0 => /usr/lib64/libboost_program_options-mt.so.1.47.0 (0x0000003c6ac00000) 
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003c6dc00000) 
    libm.so.6 => /lib64/libm.so.6 (0x0000003c68c00000) 
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003c69c00000) 
    libc.so.6 => /lib64/libc.so.6 (0x0000003c68800000) 
    libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003c69000000) 
    librt.so.1 => /lib64/librt.so.1 (0x0000003c69800000) 
    /lib64/ld-linux-x86-64.so.2 (0x0000003c68400000)

Para la vida de mí no puedo encontrar la manera de forzar g ++/ld/configure para usar mis bibliotecas más nuevas. Cualquier ayuda sería apreciada.

Fuente

2012-03-03 nerozehl

+1 para el uso de LDD – pyCthon

Usted debe verificar con la opción '-V' forma en que la ruta de búsqueda de biblioteca actual se ve así: cuando se enlaza g ++ mostrará los directorios que va a ser la búsqueda y en qué orden. Para evitar el problema, intente pasar la ruta deseada utilizando la opción '-L'. Mi suposición es que busca pathes estándar antes de la ruta local en los directorios adicionales. –

Estoy usando -L/home/nerozehl/local/lib – nerozehl

ldd no te dice a qué se vinculó el ejecutable: te dice qué objetos compartidos cargará el ejecutable cuando se ejecute. Si quieres que se cargue desde/home/nerozehl cuando se ejecuta, lo que necesita hacer una de varias cosas:

conjunto LD_LIBRARY_PATH para contener/home/nerozehl/local/lib cuando se ejecuta el programa
agregue/home/nerozehl/local/lib a ld.so.conf para que todos lo usen. Solo funciona en sistemas (como linux) que usan ld.so.conf, sin embargo.
enlace el programa con -Wl,-rpath,/home/nerozehl/local/lib. Sin embargo, solo funciona en sistemas que usan ELF u otro formato ejecutable que lo admita. También codifica el camino al ejecutable, que es algo frágil: si mueves el ejecutable a otra máquina o reorganizas tu sistema de archivos, se puede romper.

Fuente

2012-03-03 20:52:10

¿Qué programa me dirá a qué bibliotecas está vinculado el archivo? – nerozehl

@nerozehl: no hay forma de saber cuándo finaliza el enlace, ya que esa información no está almacenada en el binario. –

¿Está seguro de que su script de configuración está prestando atención a LDFLAGS? Ejecute ./configure --help y vea las opciones. Por lo general, se le llama algo así como --with-boost = y luego le da el directorio donde se encuentra el impulso. Prueba eso en su lugar. De manera similar para cualquier otra opción con la que tenga problemas.

Fuente

2012-03-03 20:22:51

GCC Sin vincular las bibliotecas correctas

Respuesta

Cuestiones relacionadas