¿Cómo se resuelven las aplicaciones a diferentes versiones de bibliotecas compartidas en tiempo de ejecución?

Question

Soy un novato de cómo funcionan las bibliotecas compartidas en Linux. Estoy tratando de entender cómo las aplicaciones resuelven diferentes revisiones de la misma biblioteca compartida en tiempo de ejecución en Linux.

Por lo que yo entiendo, una biblioteca compartida tiene tres "nombres", por ejemplo,

1. libmy.so.1.2 (de nombre real es decir, el archivo obj real)
2. libmy.so. 1 (SONAME, que está incrustado en el archivo obj real)
3. libmy.so (nombre del enlazador, a condición de que el enlazador en tiempo de enlace y embebidos en ejecutable)

al instalar la biblioteca a través de ldconfig, se creará el siguiente símbolo lic une

• (2) => (1)
• (3) => (2)

Ahora digamos que puedo compilar otra versión de la misma biblioteca con la siguiente con el nombre verdadero , libmy.so.2.0. El SONAME por directrices sería libmy.so.2.0

En el momento del enlace de la aplicación, cuál es el nombre del enlazador que proporcionaría con el indicador "-l". Siguiendo las pautas que leí (http://www.dwheeler.com/program-library/Program-Library-HOWTO/x36.htm l), ¿no tendría que ser libmy.so y, en caso afirmativo, cómo se distinguirían ambas versiones del archivo obj?

Answer 1

de versiones de objetos compartidos funciona de la siguiente manera:

Cuando se crea un objeto compartido, que le dan tanto un nombre real y un soname. Estos se utilizan para instalar el objeto compartido (que crea tanto el objeto como un enlace).

Por lo que puede terminar con la situación:

pax> ls -al xyz* 
-rw-r--r-- 1 pax paxgroup 12345 Nov 18 2009 xyz.so.1.5 
lrwxrwxrwx 1 pax paxgroup  0 Nov 18 2009 xyz.so.1 -> xyz.so.1.5 
lrwxrwxrwx 1 pax paxgroup  0 Nov 18 2009 xyz.so -> xyz.so.1 

con xyz.so.1.5 que posea la SONAME de xyz.so.1.

Cuando los enlaces de engarce en xyz.so, se sigue los enlaces de todo el camino a xyz.so.1.5 y utiliza su SONAME de xyz.so.1 para almacenar en el ejecutable. Entonces, cuando ejecuta el ejecutable, intenta cargar xyz.so.1 que apuntará a un xyz.so.1.N específico (no necesariamente la versión 1.5).

De modo que podría instalar xyz.so.1.6 y actualizar el enlace xyz.so.1 para apuntar a él en su lugar y los ejecutables ya vinculados lo usarían en su lugar.

Una ventaja de este método de múltiples capas es que se pueden tener varias bibliotecas potencialmente incompatibles con el mismo nombre (xyz.so.1.*, xyz.so.2.*), pero, dentro de cada versión principal, puede actualizar libremente ellos ya que se supone que deben estar compatible.

Al vincular nuevos ejecutables:

• los que vinculan con xyz.so va a conseguir la última versión menor de la última versión principal.
• Otros enlaces con xyz.so.1 obtendrán la última versión menor de una versión principal específica.
• Otros enlaces con xyz.so.1.2 obtendrán una versión menor específica de una versión principal específica.

Ahora guarda lo último párrafo en cuenta al examinar su comentario:

Ahora digamos que puedo compilar otra versión de la misma biblioteca con la siguiente con el nombre verdadero, libmy.so.2.0. El SONAME por directrices sería libmy.so.2.0.

No, no lo creo. Es más probable que soname sea libmy.so.2 para que pueda realizar actualizaciones menores en la secuencia 2.x y obtener el comportamiento más reciente.

Answer 2

En el momento del enlace de la aplicación, si especifica -lmy, el vinculador buscará un archivo llamado libmy.so. Encontrará este archivo y lo vinculará con el archivo ejecutable. Si este archivo es un enlace simbólico, su aplicación se vinculará con el objetivo del enlace simbólico.

El tiempo de enlace de la aplicación es el lugar para especificar qué versión de la biblioteca dinámica que desea utilizar con su aplicación.