Hacer referencia a bibliotecas para un ejecutable de Linux

Question

He escrito una aplicación en Java y con éxito compilado usando gcj . Funcionó sorprendentemente bien, pero me he encontrado con un obstáculo: Sólo puedo ejecutar el archivo ejecutable a través de un script de shell, porque tengo que especificar las rutas de la biblioteca

.

Las bibliotecas que necesito son SWT, Xerces y GNU-cripto.

¿Hay una manera de enlazar estáticamente las bibliotecas al compilar en gcj, o se trata no es una idea buena? Alternativamente, puedo especificar la (relativa) ruta de la biblioteca durante la compilación?

En la actualidad, mi concha miradas script como el siguiente:

#!/bin/sh
export LD_LIBRARY_PATH=./libs/:$LD_LIBRARY_PATH
exec ./MyJavaApp $*

Answer 1

La idea es hacer que los "sys_paths" campo estático nulo para que pudiera construir los caminos desde el valor cambiado. Ver el post aquí (Anuncio # 223 por AjaySingh516) http: //forums.sun .com / thread.jspa? messageID = 3744346 # 3744346

Class clazz = ClassLoader.class;
Field field = clazz.getDeclaredField("sys_paths");
boolean accessible = field.isAccessible();
if (!accessible)
    field.setAccessible(true);
Object original = field.get(clazz);
// Reset it to null so that whenever "System.loadLibrary" is called, it
// will be reconstructed with the changed value.
field.set(clazz, null);
try {
    // Change the value and load the library.
    System.setProperty("java.library.path", "./libs/");
    System.loadLibrary("mylibapr");
} finally {
    // Revert back the changes.
    field.set(clazz, original);
    field.setAccessible(accessible);
}

.

gcj Propiedades del sistema (Véase: propiedades admitidas por libgcj estándar)

http://gcc.gnu.org/onlinedocs/gcj/System -properties.html

.

Solución # 2 : Variable de entorno de grupos de sistemas en tiempo de compilación

http://linux.die.net/man/1/gcj

Para esto tienes que utilizar el parámetro -Djava.library.path=./libs/ con gcj

Desde manual de gcj (por encima link):

- principales = CLASSNAME

Esta opción se usa cuando se enlaza a especificar el nombre de la clase cuyo método "principal" debe ser invocado cuando se ejecuta el ejecutable resultante.

opción -dname [= valor]

Esta opción sólo se puede utilizar con "--main". Define un nombre llamado propiedad del sistema con el valor de valor. Si no se especifica valor, entonces el valor predeterminado es una cadena vacía. Estas propiedades del sistema se inicializan en el arranque del programa y se pueden recuperar en tiempo de ejecución utilizando el método de "java.lang.System.getProperty".

Nunca he trabajado con gcj pero según documentos de estas propiedades del sistema se pueden recuperar en tiempo de ejecución, por lo que será portable a otros sistemas también.

También vea: http: //gcc.gnu. org / wiki / Statically_linking_libgcj? action = mostrar y redirección = estáticamente + + vinculación libgcj

Answer 2

Para responder a la primera parte de su pregunta -

Desde la página del gcj: "Static vinculación de libgcj puede hacer que partes esenciales de libgcj a ser omitidos. Algunas partes de uso libgcj reflexión a clases de carga en tiempo de ejecución. Desde el enlazador no ve estas referencias en el momento del enlace, se puede omitir la referencia a las clases. El resultado es por lo general (pero no siempre) un "ClassNotFoundException" ser arrojado en tiempo de ejecución. se debe tener cuidado al usar esta opción ".

Para la vinculación estática de las otras bibliotecas, no estoy seguro. No he tenido una razón para hacerlo.

ejecutables

Linux son diferentes a los de Windows. Normalmente tiene un "lanzador" o algún sistema de este tipo en función de la cual exacta de ventanas que esté utilizando. Se establece el icono en eso, no en el propio ejecutable. Por lo general, las secuencias de comandos de lanzamiento se utilizan para establecer cualquier entorno que lo necesario para ejecutar el ejecutable. Una vez más, todo esto depende de su sistema exacto ventana del escritorio.

Answer 3

¿Por qué utiliza un AOT? Yo sugeriría leer el siguiente artículo . Uno de los inconvenientes que se menciona para determinar AOTs es la siguiente ...

  

aplicaciones dinámicas. Las clases que se carga la aplicación de forma dinámica en tiempo de ejecución pueden no estar disponibles para el desarrollador de aplicaciones. Estos pueden ser plug-ins de terceros, proxies dinámicos y otras clases generadas en tiempo de ejecución y así sucesivamente. Lo que el sistema tiene que incluir un intérprete de código de bytes de Java y / o un compilador JIT.