linux - mp3tag - puddletag

¿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 (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 vinculador, proporcionado al vinculador en el momento del enlace e incrustado en el ejecutable)

Cuando instale la biblioteca a través de LDCONFIG, creará los siguientes enlaces simbólicos

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

Ahora digamos que compilo otra versión de la misma biblioteca con el siguiente nombre real, 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 serán ambas versiones? del archivo OBJ se distingue?

Answer 1

1. Libs tienen diferentes versiones en el nombre.
2. Los paquetes con el nombre "lib" solo tienen libs y tienen diferentes versiones en el nombre.
3. El sistema compilará solo con la última biblioteca, a menos que defina una diferente.
4. La aplicación usa solo aquellas bibliotecas que necesita. Compruebe ldd, readelf.
5. Las aplicaciones contienen un archivo .so y .pc de enlace, verifica el sistema de rpm para qué. https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging#Devel_Packages

Answer 2

El control de versiones de objetos compartidos funciona de la siguiente manera:

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

Entonces puedes 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 posee el SONAME de xyz.so.1 .

Cuando el enlazador se vincula en xyz.so , sigue los enlaces hasta xyz.so.1.5 y usa su SONAME de xyz.so.1 para almacenar en el ejecutable. Luego, 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 que apunte a él y los ejecutables ya vinculados lo usarían en su lugar.

Una ventaja de este método multicapa es que puede tener múltiples bibliotecas potencialmente incompatibles con el mismo nombre ( xyz.so.1.* , xyz.so.2.* ) Pero, dentro de cada versión principal, puede actualizarlas libremente ya que se supone que son compatibles .

Cuando vincula nuevos ejecutables:

• Aquellos que se vinculen con xyz.so obtendrán 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.
• Aún otros enlaces con xyz.so.1.2 obtendrán una versión menor específica de una versión principal específica.

Ahora tenga en mente ese último párrafo mientras examinamos su comentario:

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

No, no lo creo. Es más probable que el libmy.so.2 sea libmy.so.2 para que pueda realizar pequeñas actualizaciones en la transmisión 2.x y obtener el comportamiento más reciente.

Answer 3

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 desea usar con su aplicación.