¿"alternativas" para bibliotecas compartidas? ¿Eso funciona siquiera?

¿"alternativas" para bibliotecas compartidas? ¿Eso funciona siquiera?

Estoy intentando vincularme a una biblioteca compartida que tiene varias implementaciones diferentes; específicamente, blas, openblas y atlas proporcionan la misma interfaz binaria a través de la /usr/lib/libblas.soalternativa en Ubuntu 14.04 (y una configuración similar pero no idéntica en 12.04). Cuando uso GCC con -lblasel vinculador, parece que en realidad se resuelve a través del vínculo alternativo a la implementación real, por lo que, por ejemplo, si tengo openblas instalado, se vinculará al binario de openblas real y si luego instalo el ejecutable resultante en un sistema donde está instalado atlas, el vinculador dinámico no podrá cargar la biblioteca porque no verá el vínculo alternativo.

¿Hay alguna manera de hacer que GCC utilice el enlace simbólico "alternativo" como objetivo dl para que realmente funcione según update-alternativeslo previsto?

Respuesta1

La resolución de enlace simbólico es una característica aquí. Al resolverlo libblas.soen libblas.so.3, el ejecutable resultante se fija a una versión específica. (Los cambios en la versión so, es decir, 3ocurren libblas.so.3cuando la interfaz binaria de la biblioteca cambia hacia atrás de manera incompatible, por lo que esto es lo que se desea.

El problema parece ser que su sistema de destino no tiene libblas.so.3, por lo que recomiendo lo siguiente:

  1. Asegúrese de que su aplicación esté vinculada a libblas.so.3, como ya está.
  2. En el sistema de destino, cree un enlace simbólico desde libblas.so real al libblas.so.3nombre requerido, de modo que este enlace simbólico se encuentre en LD_LIBRARY_PATH:

    mkdir ./mylib
    ln -s /usr/lib/libblas.so ./mylib/libblas.so.3
    LD_LIBRARY_PATH=$PWD/mylib:$LD_LIBRARY_PATH ./myexecutable
    

información relacionada