Referenzierung Bibliotheken für eine ausführbare Linux

Question

Ich habe eine Anwendung in Java geschrieben und es erfolgreich kompiliert mit gcj . Es funktionierte überraschend gut, aber ich habe in eine Hürde laufen: Ich kann nur die ausführbare Datei durch einen Shell-Skript ausführen, weil ich die Bibliothek Pfad angeben

.

Die Bibliotheken, die ich brauche, sind SWT, Xerces und GNU-Krypto.

Gibt es eine Möglichkeit zu statisch die Bibliotheken verknüpfen, wenn in gcj kompilieren, oder ist dies nicht eine gute Idee? Alternativ kann ich den (relativen) Bibliothekspfad angeben beim Kompilieren?

Zur Zeit mein Shell-Skript sieht wie folgt aus:

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

Answer 1

Die Idee ist es, das statische Feld „sys_paths“ null zu machen, so dass sie die Pfade von dem geändertenen Wert konstruieren würden. Siehe den Beitrag hier (Post # 223 von 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 Systemeigenschaften (Siehe: Standardeigenschaften von libgcj unterstützt)

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

.

Lösung 2 : Bei der Kompilierung variablen Umgebung Set-System

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

Dazu müssen Sie verwenden Parameter -Djava.library.path=./libs/ mit gcj

Aus gcj Handbuch (Link oben):

- main = CLASSNAME

Diese Option wird verwendet, wenn Sie den Namen der Klasse angeben, die Verknüpfung, deren „Haupt“ Methode aufgerufen werden soll, wenn die ausführbare Datei ausgeführt wird.

-Dname [= value]

Diese Option kann nur mit „--main“ verwendet werden. Es definiert eine Systemeigenschaft mit dem Namen Namen mit dem Wert Wert. Wenn der Wert nicht angegeben wird, dann wird standardmäßig auf die leere Zeichenfolge. Diese Systemeigenschaften bei dem Programmstart initialisiert werden und können zur Laufzeit abgerufen werden unter Verwendung des „java.lang.System.getProperty“ -Methode.

Ich habe noch nie mit gcj gearbeitet, aber wie pro docs können diese Systemeigenschaften zur Laufzeit abgerufen werden, daher wird es auf andere Systeme als auch tragbar sein.

Siehe auch: http: //gcc.gnu. org / wiki / Statically_linking_libgcj? action = Show & redirect = Statisch + Verknüpfung + libgcj

Answer 2

Um den ersten Teil Ihrer Frage zu beantworten -

Von der gcj Manpage: „Static von libgcj Verknüpfung verursachen kann wesentliche Teile libgcj weggelassen werden. Einige Teile von libgcj Verwendung Reflexion Belastungsklassen zur Laufzeit. Da der Linker, nicht über diese Referenzen zur Verknüpfungszeit sieht es die genannten Klassen weglassen. Das Ergebnis ist, in der Regel (aber nicht immer) eine „ClassNotFoundException“ zur Laufzeit geworfen. Vorsicht verwendet werden müssen, wenn Sie diese Option verwenden. "

Für die statische Verknüpfung der anderen Bibliotheken, ich bin sicher nicht. Ich hatte keinen Grund, das zu tun.

Linux ausführbare Dateien sind anders als Windows. Normalerweise haben Sie einen „launcher“ oder so abhängig von der genauen Windowing-System Sie verwenden. Sie setzen auf das Symbol, dass nicht auf die ausführbare Datei selbst. Üblicherweise werden Start-Skripte verwendet, um jede Umgebung einzustellen, dass Sie für die ausführbare Datei ausgeführt wird. Auch dies alles auf Ihrem genauen Desktop-Fenstersystem abhängig ist.

Answer 3

Warum verwenden Sie eine AOT? Ich würde vorschlagen, den folgenden Artikel lesen. Einer der Nachteile, dass es für AOTS erwähnt ist die folgende ...

  

Dynamische Anwendungen. Klassen, die die Anwendung laden dynamisch zur Laufzeit können mit dem Anwendungsentwickler nicht verfügbar sein. Diese können Drittanbieter-Plug-In sein, dynamischen Proxies und andere Klassen generierten zur Laufzeit und so weiter. So das Laufzeitsystem ein Java-Bytecode-Interpreter enthalten und / oder einen JIT-Compiler.