Barrapunto

También puedes parchear un binario. ¿Nunca has ejecutado un patch de un programa para evitar molestas cuentas atrás o peticiones de claves? Que el binario esté separado en dos tiene ciertas ventajas. Y si además conserva la tabla de símbolos porque el enlazado aún no se ha completado, más ventajas todavía. Aún y todo, la nueva biblioteca y el binario original darán fruto a un único programa después del enlazado. También puedes cambiar un .o por otro .o y re-enlazarlo todo, lo cual no hace a unos .o independientes de otro en lo que al programa se refiere. Tu argumentación es débil.

Es muy sencillo. En enlazado dinámico sigue siendo un enlazado. Y no hace unas partes del código más interdependientes que otras de lo que lo hace el enlazado estático (y no me refiero solo a las bibliotecas de enlazado estático, que no son más que grupos de .o empaquetados con ar, también cuenta cualquier otro tipo de código objeto). Con tu razonamiento, si el código está escrito en ficheros separados, tampoco formaría parte del mismo programa. El enlazado estático no es más que un caso particular de enlazado dinámico. Es un que se realiza antes de la carga del programa, en lugar de durante la carga del programa. Pero cualquier binario es susceptible de ser separado en un montón de objetos de enlazado dinámico (salvo uno), tan solo cambiando las opciones de compilación. Y esos son hechos puramente técnicos.

PD: El caso de los plug-in, por cierto, es diferente. Un plug-in, aunque utilice la infraestructura de las bibliotecas compartidas, se utiliza como un "repositorio de código". No se enlaza con el programa, en realidad. Se lee función a función del archivo en disco. Ahí la cosa es un poco más complicada, ya que el que programó el código de carga de la biblioteca no sabía qué iban a meter ahí.