linux - para - mp3 tagger for mac

¿Cuál es el método aceptado para implementar una aplicación de Linux que se basa en bibliotecas compartidas?

Question

Tengo una aplicación que se basa en Qt, GDCM y VTK , con el entorno de compilación principal siendo Qt. Todas estas bibliotecas son multiplataforma y se compilan en Windows, Mac y Linux. Necesito implementar la aplicación en Linux después de implementarla en Windows. Las versiones de vtk y gdcm que estoy usando son versiones troncales de git (de aproximadamente un mes de antigüedad), más recientes que las que puedo obtener en Ubuntu 11.04, que es mi objetivo de implementación actual de Linux.

¿Cuál es el método aceptado para implementar una aplicación que se basa en este tipo de bibliotecas?

¿Debería estar enlazando estáticamente aquí, para evitar LD_LIBRARY_PATH? Veo informes conflictivos en LD_LIBRARY_PATH; Los tutoriales como este sugieren que es la "manera correcta" de modificar la ruta de la biblioteca para usar bibliotecas compartidas a través de reinicios del sistema. Others suggest que nunca debería establecer LD_LIBRARY_PATH. En la versión predeterminada de GDCM, la instalación ya coloca las bibliotecas en el directorio /usr/local/lib , por lo que esas bibliotecas se ven cuando ejecuto ldd <my program> . VTK, por otro lado, coloca sus bibliotecas en /usr/local/lib/vtk-5.9 , que no forma parte de LD_LIBRARY_PATH en la mayoría de las máquinas de los usuarios, por lo que no se encuentra a menos que se realice algún cambio en el sistema. Copiar los archivos VTK en ''/ usr / local / lib'' no permite que ''ldd'' vea los archivos.

Entonces, ¿cómo puedo hacer que mi aplicación vea VTK para usar las bibliotecas?

En Windows, la implementación de las DLL es muy sencilla, ya que solo puedo incluirlas en el instalador y la aplicación las encuentra porque están en el directorio local. Ese enfoque no funciona en Linux, por lo que iba a hacer que los usuarios instalen Qt, GDCM y VTK desde cualquier fuente apropiada y usen las ubicaciones predeterminadas, y luego hagan que la aplicación apunte a esas ubicaciones predeterminadas. Sin embargo, dado que VTK está poniendo las cosas en una ubicación no estándar, ¿debería esperar también que los usuarios modifiquen LD_LIBRARY_PATH? ¿Debo incluir las versiones específicas de las bibliotecas que deseo y luego descubrir cómo hacer que el ejecutable se vea en el directorio local de esas bibliotecas e ignorar las que se encuentran en la ruta de la biblioteca?

Answer 1

Bueno, hay dos opciones para desplegar la aplicación Linux.

La forma correcta:

• haga un paquete para su aplicación y para las bibliotecas, si son tan especiales, que no puedan instalarse desde repositorios estándar

• Hay dos formatos de paquetes principales. RPM y DEB.

La manera fácil:

• haga un archivo autoextraíble que instale "Windows Way" en /opt .

• Puedes tener bibliotecas en el mismo directorio que el ejecutable, simplemente no es la forma preferida.

Answer 2

En general, lo mejor es que dependan de las versiones "normales" de las bibliotecas para cualquier distribución que esté dirigiendo (y dicen que no son compatibles con dists que no son compatibles con versiones suficientemente recientes de la biblioteca), pero si REALMENTE necesita depender de una versión -Wl,-rpath,''$ORIGIN'' compartida, puede vincular su aplicación con -Wl,-rpath,''$ORIGIN'' y luego instalar una copia de la versión exacta que desee en el mismo directorio que su ejecutable.

Tenga en cuenta que si usa make, necesitará $$ en el makefile para obtener un solo $ en el argumento que realmente se envía al vinculador. Los qutoes individuales son necesarios para que la cáscara no munge las cosas ...

Answer 3

Todas las aplicaciones comerciales "serias" que he visto usan LD_LIBRARY_PATH . Invariablemente incluyen un script de shell que se parece a esto:

#!/bin/sh

here="${0%/*}"  # or you can use `dirname "$0"`

LD_LIBRARY_PATH="$here"/lib:"$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH
exec "$0".bin "$@"

.wrapper este script algo así como .wrapper y crean un árbol de directorios que se ve así:

.wrapper
lib/  (directory full of .so files)
app1 -> .wrapper (symlink)
app1.bin (executable)
app2 -> .wrapper (symlink)
app2.bin (executable)

Ahora puedes copiar todo este árbol a donde quieras, y puedes ejecutar "/ path / to / tree / app1" o "/ path / to / tree / app2 --with --some --arguments" y funcionará . Así será poniendo / ruta / a / árbol en su RUTA.

Por cierto, así es como Firefox y Chrome lo hacen, más o menos.

Quien te haya dicho que no uses LD_LIBRARY_PATH está lleno de eso, IMHO.

Las bibliotecas de sistema que desea colocar en lib dependen de las versiones de Linux que desee admitir oficialmente.

Ni siquiera pienses en la vinculación estática. A los desarrolladores de glibc no les gusta, no les importa que lo apoyen y, de alguna manera, logran romperlo un poco más con cada lanzamiento.

Buena suerte.