Tienes la versión dinámica de una librería (el .so)
No tienes la versión estática de la librería (el .a)
No tienes el código fuente de la librería
¿puedes generar un ejecutable totalmente estático que use objetos de la librería?
En principio he pensado en jugar con nm, objdump, objcopy, readelf, etc. para intentar sacar las funciones que quiero, pero no sé si al estar el código compilado como PIC va a ser viable, además de los posibles datos estáticos, inicializadores y otras dependencias con las que habría que lidiar.
Pues para el escenario que describía en la pregunta original, totalmente.
Pero déjame elevar los requisitos, el escenario busca aligerar contenedores Docker de modo que lleven un ejecutable con todo el código necesario (sin dependencias de código externas). Cuando tienes el código de todo hay menos problema, pero en cuanto sólo dispones de la librería dinámica de algo, adiós a tu sueño.
Para eso ya no se me ocurre nada fino sin ponerme a estudiar por los internés de los porteadores.
Entiendo que estás hablando de apps no gráficas. A bote pronto se me ocurre:
hacerte un appimage donde ya tienes todo empaquetado del tirón y que supongo que puedes invocar directamente desde el contenedor
hacer un paquete snap
tirar del workflow de flatpak pero en lugar de publicarlo flatpak usar el FS (el nativo creo que va sobre OSTree) o exportarlo a un árbol de ficheros que podrías luego meter en tu imagen docker
o, tal vez, hacerte todo el entorno empotrado con Yocto.
Todo esto es casi hablar por hablar pq no me he estudiado el escenario.
El caso es que docker en sí ya es algo equivalente al empaquetado que te haga snap, flatpack. Lo que busco es reducir el tamaño de la imagen. Para que meter 30 .so con 200 funciones, si mi código sólo llama a 40 funciones. Compilando en estático solo añades los objetos necesarios a tu ejecutable. Con .so, tienes una copia con todas las funciones, aunque no las uses.
Eso si tiene sentido a nivel de sistema operativo, ya que el .so es compartido por n aplicaciones (y procesos en ejecución), pero en contenedores , pues es otra historia. Si, puedo tener librerías comunes en una capa común de la que partan todas mis imágenes, pero en entornos abiertos dónde cada uno sube su propia imagen se acabaron las ventajas. Y al final en docker pasa eso. Incluso habrá imagenes que usen el mismo .so, pero uno proveniente del empaquetado de Fedora, otro de Debian, etc.
Si hubiese una forma de generar estos ejecutables autocontenidos, pues sería un avance a la hora de crear imágenes.