Vinculación estática con glibc y libstdC++

Estoy escribiendo una aplicación multiplataforma que no es compatible con GNU GPL. El principal problema al que me enfrento actualmente es que la aplicación está vinculada dinámicamente con glibc y libstdC++, y casi todas las nuevas actualizaciones importantes de las bibliotecas no son compatibles con versiones anteriores. Por lo tanto, los bloqueos aleatorios se ven en mi aplicación.Vinculación estática con glibc y libstdC++

Como solución alternativa, distribuyo binarios de mi aplicación compilados en varios sistemas diferentes (con diferentes versiones de tiempo de ejecución C/C++). Pero quiero prescindir de esto. Entonces, mi pregunta es, manteniendo las licencias y todo en mente, ¿puedo vincular estáticamente contra glibc y libstdC++? Además, ¿esto causará problemas con rtld?

Fuente

2010-07-09 themoondothshine

Los mantenedores de glibc y libstdC++ hacen un gran trabajo para mantener la compatibilidad binaria hacia atrás. Los principales lanzamientos lo rompen por diseño, pero estos no ocurren con demasiada frecuencia. Probablemente resolvería su problema construyendo binarios en un sistema no muy moderno, o usando algunas herramientas LSB de The Linux Foundation (vea [aquí] (http://www.linuxfoundation.org/collaborate/workgroups/lsb); las herramientas son gratuitas, y sí, trabajé para ellas, así que soy parcial). –

La especificación de la opción -static-libgcc en el vinculador haría que se vincule con una versión estática de la biblioteca C, si está disponible en el sistema. De lo contrario, es ignorado.

Fuente

2011-01-15 19:25:42 themoondothshine

También necesita '-static-libstdC++', consulte [explicación] (http://www.trilithium.com/johan/2005/06/static-libstdc/) – ACyclic

Esta es una respuesta * completamente * falsa: '-estática -libgcc' no tiene * nada * que ver con la biblioteca del sistema C. –

@themoondothshine deberías * en serio * corregir esta respuesta. Como lo señala el ruso empleado 'libgcc! = Libc' (y eso independientemente de si dicho 'libc == glibc' o no). 'libgcc' es una biblioteca en tiempo de ejecución para admitir el código generado por el compilador. Lea sobre esto [aquí] (https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html). – 0xC0000022L

No es necesario.

Copie las bibliotecas originales vinculadas en un directorio (../lib en este ejemplo) en la carpeta de la aplicación.

igual:

my_app_install_path

.bin
lib
documentación

cambia el nombre de aplicación para algo así como app.bin. Sustituya su aplicación por un pequeño script de shell que establezca la variable de entorno LD_LIBRARY_PATH en la ruta de acceso de la biblioteca (y concatene el contenido LD_LIBRARY_PATH anterior, si corresponde). Ahora debería poder encontrar las bibliotecas dinámicas con las que se vinculó y no necesita compilarlas estáticamente en su ejecutable.

Recuerde cumplir con la LGPL al agregar la atribución dada a las bibliotecas y al señalar en la documentación donde se puede descargar la fuente.

Fuente

2010-07-09 15:41:09

@Vitor: ¡Esta es la mejor solución, creo! De todos modos distribuyo todas las dependencias de terceros (es decir, zlib, libssh, openssl, yada yada ...) como bibliotecas compartidas con el paquete. El único requisito que impongo a los usuarios es que tengan el tiempo de ejecución C/C++ estándar instalado en su sistema. Si lo que dices funciona, ya tengo la infraestructura: ¡La aplicación es básicamente un servicio, por lo que todos los scripts ya están en su lugar! – themoondothshine

@Vitor: Tengo otra pregunta: ¿Podrán las nuevas versiones de RTLD cargar dinámicamente todas las bibliotecas incluso si están compiladas en sistemas realmente antiguos? Es decir, no tendría que preocuparme de que ld cause problemas de tiempo de ejecución si envío libstdC++ y glibc con mi aplicación, ¿verdad? – themoondothshine

@themoondothshine Nunca tuve un problema con ld no pudiendo cargar todas las bibliotecas. He estado haciendo esto durante los últimos 3 años para enviar un paquete GIS de código cerrado en Linux. –

-1

Debo preguntar qué diablos estás haciendo con las pobres funciones de la biblioteca?

Tengo también un software multiplataforma. Funciona bien en sistemas Linux de todo tipo. Compila con la versión más antigua de software que quieras admitir. Las bibliotecas glibc y libstdC++ son realmente muy compatibles.

He creado CentOS 4 y lo ejecuto en RHEL 6 beta. No hay problemas. Puedo construir en Debian estable y ejecutarlo en las pruebas.

Ahora, a veces tengo problemas con algunas bibliotecas si trato de construir, digamos Debian antiguo e intento ejecutarlo en CentOS 5.4. Esto generalmente se debe a las opciones de configuración de distribución que son diferentes, como elegir enhebrar o no enhebrar.

Fuente

2010-07-09 15:57:53

Déjame decirte exactamente lo que sucedió: Solía compilar mis binarios en CentOS 3.9 (con una versión anterior de glibc - 2.3.algo). Ahora, este binario comenzó a fallar en CentOS 5.4 y los volcados del núcleo no apuntaban a ningún lado. Finalmente fui a los desarrolladores de CentOS y se sorprendieron de que la aplicación funcionó durante casi un mes sin incidentes en CentOS 5.4. Me sugirieron que use el sistema MockBuild de Fedora, pero decidí ir a compilar de forma nativa en múltiples plataformas. Entonces, lo que estoy haciendo con las funciones de la biblioteca no es tanto el problema como la compatibilidad con versiones anteriores. – themoondothshine

Eso no es verdad. Recientemente, tenemos un cliente que ejecuta el sistema basado en glibc-2.7 que causó que todos los programas en C++ generados contra glibc-2.1X fallaran al ejecutarse, algunos símbolos faltaban en libstdC++. So.X (al menos iostream), además de CentOS está basado en RedHat, y ambos con una biblioteca compartida no tan reciente (a diferencia de otras distribuciones), por lo que no me convence demasiado. – daisy

glibc está bajo la LGPL. En la sección 6. de LGPL 2.1, puede distribuir su programa vinculado a la biblioteca siempre que cumpla con una de las cinco opciones. El primero es proporcionar el código fuente de la biblioteca, junto con el código del objeto (la fuente es opcional, no requerida) de su propio programa, por lo que se puede volver a vincular con la biblioteca. Alternativamente, puede proporcionar una oferta por escrito de la misma. Su propio código no tiene que estar bajo la LGPL, y no tiene que liberar la fuente.

libstdC++ está bajo la GPL, pero con un major exception. Básicamente puede simplemente distribuir bajo la licencia de su elección sin proporcionar la fuente de su propio código o libstdC++. La única condición es que compile normalmente, sin, p. modificaciones propietarias o complementos para GCC.

IANAL, y debería considerar consultar uno si necesita asesoramiento legal real.

Fuente

2010-07-09 16:00:58

Vinculación estática con glibc y libstdC++

Respuesta

Cuestiones relacionadas