Por lo general, cuando crea objetos compartidos (.so), también se encarga de las versiones agregando sufijos como mylib.so.2.3.1. Para asegurarse de que sus programas puedan cargar esta biblioteca u otras versiones posteriores, cree enlaces con nombres
mylib.so -> mylib.so.2.3.1
mylib.so.2 -> mylib.so.2.3.1
mylib.so.2.3 -> mylib.so.2.3.1
Entonces, todo después de .so representa version.sub-version.build (o similar) Además, es posible que más de una versión de la misma lib coexista con este esquema, y todo lo que es necesario para cambiar programas para usar un particular versión es tener los enlaces apropiados en su lugar.
El binario ELF enlazado dinámicamente (ya sea otra biblioteca o un ejecutable) usa un nombre de objeto compartido o soname para identificar la biblioteca a la que se debe vincular el ejecutable en el momento de la ejecución.
Cuando se crea una biblioteca como biblioteca compartida ELF, el editor de enlaces en tiempo de compilación inserta un campo DT_SONAME en el ejecutable que es el SONAME de la biblioteca en la propia biblioteca. El DT_SONAME se define en el estándar ELF como:
Este elemento contiene el desplazamiento de la tabla de cadenas de una cadena terminada en nulo, dando el nombre del objeto compartido. El desplazamiento es un índice en la tabla registrada en el DT_STRTAB entrada. Consulte "Dependencias de objetos compartidos" a continuación para obtener más información sobre estos nombres.
Entonces, ahora, cuando se crea un ejecutable, el SONAME está incrustado en él. Cuando se ejecuta el ejecutable, el enlazador lo usa para buscar la biblioteca en los archivos en las ubicaciones predefinidas para la biblioteca dinámica. La ubicación predefinida en Windows sería donde residan las DLL. En Linux y Mac OS X y otros sistemas compatibles con System V serían /lib y /usr/lib y posiblemente otros puntos, depende del enlazador utilizado, y se puede definir en las propias configuraciones de los enlazadores.
En todos los casos, el enlazador busca si la biblioteca nombrada en la entrada de soname está presente en alguna de esas ubicaciones, si es así, la usará.
Tenga en cuenta que el estándar dice que el soname es una CADENA y las convenciones de versiones se convirtieron en un estándar de facto después del hecho y dice algo como esto:
Haz que el soname sea libmyname.so.A y haga que el nombre del archivo de la biblioteca sea libmyname.so.A.B o libmyname.so.A.B.C (en MacOSX es libmyname.A.B.dylib). Crear un enlace suave desde libmyname.so.A.B[.C]? a libmyname.so.A .
A se mantiene igual mientras que el ABI de la biblioteca permanece igual.
B (o B.C ) se convierte en la versión secundaria.
En Linux, es muy común que la versión de la biblioteca sea la misma que el número de versión del paquete. Esto tiene sus pros y sus contras.
formalización de libtool
GNU libtool se usa mucho para crear bibliotecas dinámicas y tiene un sistema de versiones más formal y tiene una lógica sólida para ello. El sistema de versiones libtool para sonames funciona muy bien y es adoptado por bibliotecas complejas para mantener las cosas en orden.
En libtool, el control de versiones es el siguiente:
libmylib-actual .liberar .edad
Bajo libtool, la idea es que a medida que las bibliotecas evolucionen, agregarán y eliminarán funcionalidades.
Digamos que está desarrollando una biblioteca. Comience usando una versión como 0.0.0 .
Ahora supongamos que corrige algunos errores, solo aumentaría la versión número.
Entonces, el nuevo nombre sería libmylib.0.1.0 o libmylib.0.2.0, etc. para cada versión que solo corrige errores pero no cambia nada de ABI.
Por el camino dices. ¡Puaj! Podría haber hecho mejor esta subfuncionalidad, por lo que agrega un nuevo conjunto de funciones para hacer algo mejor, pero debido a que otros todavía están usando su biblioteca, aún deja la funcionalidad anterior (obsoleta) allí.
Las reglas son las siguientes:
-
Comience con la información de versión de '0:0:0' para cada biblioteca libtool.
-
Actualice la información de la versión solo inmediatamente antes del lanzamiento público de su software. Las actualizaciones más frecuentes son innecesarias y solo garantizan que el número de interfaz actual crezca más rápido.
-
Si el código fuente de la biblioteca ha cambiado desde la última actualización, aumente la revisión ('c:r:a' se convierte en 'c:r+1:a').
-
Si se agregaron, quitaron o cambiaron interfaces desde la última actualización, incremente la actual y establezca la revisión en 0.
-
Si se han agregado interfaces desde el último lanzamiento público, aumente la antigüedad.
-
Si se eliminó o cambió alguna interfaz desde el último lanzamiento público, establezca la antigüedad en 0.
Puede leer más sobre esto en la documentación de libtool
Actualizar...
El siguiente fue un comentario de que mi explicación tiene un error. No lo hace, lo que requiere un poco más de detalle de lo que se puede poner en un comentario de respuesta, así que consulte a continuación.
Objeción original
Aquí hay un error:en Linux, la versión es de formlibmylib.(current-age).release.age, donde los paréntesis indican una expresión a evaluar. Por ejemplo, GLPK 4.54 withcurrent:revision:age =37:1:1 en Linux instala el archivo de biblioteca libglpk.so.36.1.1. Para obtener más información, consulte, por ejemplo,
Refutación
TLDR:autotools.io no es una fuente autorizada. ExplicaciónSi bien Flameeyes es un desarrollador increíble y es uno de los mantenedores de Gentoo, fue él quién cometió el error y creó una interpretación vaga de "regla general" de la especificación libtool. Si bien esto no va a romper los sistemas el 99% del tiempo, si tuviéramos que seguir la forma ad-hoc de actualizar actual :
Las reglas generales, cuando se trata de estos valores son:
Aumente siempre el valor de revisión.
Aumente el valor actual cada vez que se agregue, elimine o cambie una interfaz.
Aumente el valor de antigüedad solo si los cambios realizados en la ABI son compatibles con versiones anteriores.
Luego continúa diciendo que para mantener varias versiones de Gtk, sería mejor simplemente agregar la versión de la biblioteca en el NOMBRE de la biblioteca y simplemente volcar el número de versión. (como lo hacen en GTK+):
En esta situación, la mejor opción es agregar parte de la información de la versión de la biblioteca al nombre de la biblioteca, que se ejemplifica con el soname libglib-2.0.so.0 de Glib. Para hacerlo, la declaración en theMakefile.am tiene que ser así:
lib_LTLIBRARIES = libtest-1.0.la
libtest_1_0_la_LDFLAGS = -version-info 0:0:0
Bueno, ese es solo un enfoque crockpot para arruinar el poder de los enlaces dinámicos y el control de versiones de resolución de símbolos completamente discutible. Está diciendo que simplemente lo apagues. ¡Mocos de caballos! No es de extrañar que incluso los desarrolladores experimentados hayan tenido dificultades para crear y mantener proyectos de código abierto y constantemente nos encontramos con binarios que mueren cada vez que se instalan nuevas versiones de bibliotecas (porque se golpean entre sí).
El enfoque de control de versiones de libtool está MUY BIEN PENSADO . Es un algoritmo y sus pasos están ordenados instrucciones 1 a 6 deben seguirse cada vez que haya una actualización del código de una biblioteca vinculada dinámicamente.
Para los desarrolladores nuevos y actuales, léalos detenidamente y visualice lo que sucederá con el número de versión de la biblioteca a lo largo de la vida útil de su increíble software. Si lo hace, notará que todas las piezas de software previamente vinculadas siempre usará correctamente la versión más actual y precisa de su increíble biblioteca, y ninguno de ellos alguna vez se golpearán o pisotearán unos a otros, Y nunca tienes que agregar un número floreciente en el nombre de tu biblioteca (a menos que sea por placer o estética).