¿Objetos compartidos portátiles?

Question

¿Es posible usar archivos de objetos compartidos de forma portátil como las DLL en Windows?

Me pregunto si hay una manera de proporcionar una biblioteca compilada, lista para usar, para Linux. De la misma manera, puede compilar un archivo DLL en Windows y puede usarse en cualquier otro Windows (está bien, no en CUALQUIER otro, pero en la mayoría de ellos puede).

¿Es eso posible en Linux?

EDITAR:
Acabo de despertar y leer las respuestas. Hay algunos muy buenos.
No estoy tratando de ocultar el código fuente. Solo quiero proporcionar una biblioteca ya compilada y lista para usar, para que los usuarios sin experiencia en compilación no necesiten hacerlo ellos mismos.
Por lo tanto, la idea es proporcionar un archivo .so que funcione en tantos Linux diferentes como sea posible.
La biblioteca está escrita en C ++, utilizando las bibliotecas STL y Boost.

Answer 1

I altamente altamente recomiendo usar la aplicación LSB / corrector de biblioteca. Te lo dirá rápidamente si:

• Están usando extensiones que no están disponibles en algunas distribuciones
• Introduce bash-isms en tus scripts de instalación
• Use syscalls que no están disponibles en todos los núcleos recientes
• Depende de bibliotecas no estándar (le dirá qué distribuciones les faltan)
• Y muchos, sobre muchos otros cheques muy buenos

Puede obtener más información aquí , así como descargar la herramienta. Es fácil de ejecutar ... simplemente descomprímalo, ejecute un script perl y apunte su navegador a localhost ... el resto está controlado por el navegador.

Usando la herramienta, puede obtener fácilmente su biblioteca / aplicación LSB certificada (para ambas versiones) y hacer que el trabajo del empaquetador de distro sea mucho más fácil.

Más allá de eso, solo use algo como libtool (o similar) para asegurarse de que su biblioteca esté instalada correctamente, proporcione un objeto estático para las personas que no desean vincularse con el DSO (tomará tiempo para que su biblioteca aparezca en la mayoría de las distribuciones, por lo que escribir un programa portátil, no puedo contar con que esté presente) y comentar bien su interfaz pública.

Para las bibliotecas, encuentro que Doxygen funciona mejor. La documentación es muy importante, seguramente influye en mi elección de biblioteca para usar en cualquier tarea.

Realmente, nuevamente, revisa el verificador de aplicaciones, te dará informes de problemas de portabilidad que tomarían un año de tener la biblioteca en la naturaleza para obtener lo contrario.

Finalmente, trate de hacer que su biblioteca sea fácil de colocar 'en el árbol', para que no tenga que enlazar estáticamente contra ella. Como dije, podrían pasar un par de años antes de que se vuelva común en la mayoría de las distribuciones. Es mucho más fácil para mí simplemente tomar su código, soltarlo en src / lib y usarlo, hasta que su biblioteca sea común. Y por favor, por favor ... dame pruebas unitarias, TAP (prueba cualquier protocolo) es Una forma buena y portátil de hacerlo. Si pirateo su biblioteca, necesito saber (rápidamente) si la rompí, especialmente al modificarla en árbol o en situ (si existe el DSO).

Answer 2

Si desea ayudar a sus usuarios dándoles código compilado, la mejor manera que conozco es dándoles un binario estático + documentación sobre cómo pueden ejecutar el binario. (Posiblemente, además de proporcionarles el código fuente). La mayoría de los archivos binarios vinculados estáticamente funcionan en la mayoría de las distribuciones de Linux de la misma arquitectura (+ 32 bits (x86) los archivos binarios enlazados estáticamente funcionan en 64 bits (amd64)). No es de extrañar que Skype proporcione una descarga de Linux estáticamente vinculada.

Volver a la pregunta de tu biblioteca. Incluso si es un experto en escribir bibliotecas compartidas en Linux, y se toma su tiempo para minimizar las dependencias para que su biblioteca compartida funcione en diferentes distribuciones de Linux, incluidas las versiones antiguas y nuevas, no hay forma de asegurarse de que funcione en el futuro (digamos, 2 años). Lo más probable es que termines manteniendo el archivo .so, es decir, haciendo pequeñas modificaciones una y otra vez para que el archivo .so sea compatible con las versiones más recientes de las distribuciones de Linux. No es divertido hacerlo durante mucho tiempo, y disminuye sustancialmente su productividad: el tiempo que dedica a mantener la compatibilidad de la biblioteca habría sido mucho mejor dedicado, p. mejorando la funcionalidad, eficiencia, seguridad, etc. del software.

Tenga en cuenta también que es muy fácil molestar a sus usuarios al proporcionar una biblioteca en formato .so, que no funciona en su sistema. (Y no tiene la superpotencia para que funcione en todos sistemas Linux, por lo que esta situación es inevitable). ¿Proporciona también 32 bits y 64 bits, incluidos x86, PowerPC, BRAZO, etc.? Si el archivo .so solo funciona en Debian, Ubuntu y Red Hat (porque no tiene tiempo para transferir el archivo a más distribuciones), lo más probable es que moleste a sus usuarios de SUSE y Gentoo (y más).

Answer 3

Idealmente, querrás usar GNU autoconf , automake , y libtool para crear configurar y crear scripts, luego distribuir la biblioteca como fuente con los archivos de configuración y Makefile.in generados.

Aquí hay un libro en línea sobre ellos.

./configure; hacer; make install es bastante estándar en Linux.

La raíz del problema es que Linux se ejecuta en muchos procesadores diferentes. No puede confiar únicamente en el procesador que admite instrucciones x86 como lo hace Windows (para la mayoría de las versiones: Itanium (XP y más reciente) y Alpha (NT 4.0) son las excepciones).

Answer 4

Entonces, la pregunta es, ¿cómo desarrollar bibliotecas compartidas para Linux? Puede echar un vistazo a este tutorial o el tutorial de Pogram Library .

Answer 5

Sé lo que estás preguntando. Para Windows, MSFT ha hecho que todas las DLL sean compatibles, por lo que sus DLL son generalmente compatibles para casi todas las versiones de Windows, por eso lo llama "portátil".

Desafortunadamente, en Linux hay demasiadas variaciones (y todos piensan ser "diferentes" para ganar dinero) para que no pueda obtener los mismos beneficios que Windows, y es por eso que tenemos muchos paquetes iguales compilados para diferentes distribuciones , versión de distribución, tipo de CPU, ...

Algunos dicen que el problema es causado por la arquitectura (CPU), pero no lo es. Incluso en el mismo arco, todavía hay diferencias entre las distribuciones. Una vez que haya intentado realmente lanzar un paquete binario, sabrá lo difícil que es, incluso la dependencia de la biblioteca de tiempo de ejecución C es difícil de mantener. El sistema operativo Linux carece de demasiadas cosas, por lo que casi todos los servicios implican problemas de dependencia.

Por lo general, solo puede construir algunos binarios que sean compatibles con alguna distribución (o varias distribuciones si tiene suerte). Es por eso que lanzar programas de Linux en binario siempre se arruinó, a menos que esté vinculado a alguna distribución como Ubuntu, Debian o RH.

Answer 6

Simplemente poner un archivo .so en / usr / lib puede funcionar, pero es probable que estropee el esquema que tiene su distribución para administrar bibliotecas.

Eche un vistazo a la base estándar de Linux: eso es lo más parecido que encontrará a una plataforma común entre las distribuciones de Linux.

http://www.linuxfoundation.org/collaborate/workgroups/lsb

¿Qué estás tratando de lograr?

Answer 7

La respuesta de Tinkertim es acertada. Agregaré que es importante comprender y planificar los cambios en gcc's ABI . Las cosas han sido bastante estables recientemente y creo que todas las distribuciones principales están en gcc 4.3.2 más o menos. Sin embargo, cada pocos años parece que cambio a la ABI (especialmente los bits relacionados con C ++) causar caos, al menos para aquellos que desean lanzar binarios de distribución cruzada y para los usuarios que se han acostumbrado a recoger paquetes de otras distribuciones de las que realmente ejecutan y encuentran que funcionan. Mientras se está llevando a cabo una de estas transiciones (todas las distribuciones se actualizan a su propio ritmo), lo ideal es lanzar libs con ABI que admitan la gama completa de versiones de gcc que usan los usuarios.