Bibliothèques référençant pour un exécutable Linux

Question

J'ai écrit une application en Java et compilé avec succès à l'aide de gcj . Cela a fonctionné étonnamment bien, mais j'ai couru dans un obstacle: je ne peux pas exécuter l'exécutable par un script shell, parce que je dois spécifier les chemins de bibliothèque

.

Les bibliothèques dont j'ai besoin sont SWT, Xerces et GNU-Crypto.

Y at-il un moyen de lier statiquement les bibliothèques lors de la compilation dans gcj, ou est-ce pas une bonne idée? Sinon, puis-je spécifier le chemin de la bibliothèque (relative) lors de la compilation?

À l'heure actuelle, mon script shell ressemble à ceci:

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

Answer 1

L'idée est de rendre le champ statique null « de sys_paths » afin qu'il construirait les chemins de la valeur modifiée. Voir le message ici (Post # 223 par 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 Propriétés système (Voir: Propriétés standard pris en charge par libgcj)

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

.

Solution # 2 : Définir la variable d'environnement système au moment de la compilation

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

Pour cela, vous devez utiliser le paramètre -Djava.library.path=./libs/ avec gcj

Manuel d'gcj (lien ci-dessus):

- principal = CLASSNAME

Cette option est utilisée lors de la liaison pour spécifier le nom de la classe dont la méthode « principale » doit être invoqué lorsque l'exécutable résultant est exécuté.

-Dname [= valeur]

Cette option ne peut être utilisée avec « --main ». Il définit une propriété du système appelé nom avec la valeur de la valeur. Si la valeur est pas spécifiée, la valeur par défaut de la chaîne vide. Ces propriétés du système sont initialisés au démarrage du programme et peuvent être récupérés lors de l'exécution en utilisant la méthode « java.lang.System.getProperty ».

Je ne l'ai jamais travaillé avec gcj mais comme par docs ces propriétés du système peuvent être récupérées lors de l'exécution, d'où il sera portable à d'autres systèmes.

Voir aussi: http: //gcc.gnu. org / wiki / Statically_linking_libgcj? action = show & redirect = statiquement + + liens libgcj

Answer 2

Pour répondre à la première partie de votre question -

A partir de la page man gcj: « Liaison statique de libgcj peut provoquer des parties essentielles de libgcj à être omis. Certaines parties de la réflexion de l'utilisation des libgcj pour charger les classes lors de l'exécution. Depuis l'éditeur de liens ne voit pas ces références à l'heure du lien, il peut omettre l'appelé classes. Le résultat est généralement (mais pas toujours) un « ClassNotFoundException » d'être jeté à l'exécution. il faut se méfier lors de l'utilisation de cette option. "

Pour la liaison statique des autres bibliothèques, je ne suis pas sûr. Je n'ai pas eu raison de le faire.

Linux executables sont différents que Windows. Normalement, vous avez un « lanceur » ou quelque chose comme selon le système de fenêtrage exact que vous utilisez. Vous définissez l'icône que, non sur l'exécutable lui-même. Habituellement, les scripts de lancement sont utilisés pour définir tout type d'environnement que vous avez besoin pour exécuter l'exécutable. Encore une fois, tout dépend de votre système exacte de la fenêtre de bureau.

Answer 3

Pourquoi utilisez-vous un AOT? Je vous suggère de lire article suivant . L'un des inconvénients qu'il mentionne pour AOT est le suivant ...

  

applications dynamiques. Les classes que les charges d'application dynamiquement lors de l'exécution peuvent être indisponibles pour le développeur d'applications. Ceux-ci peuvent être des plug-ins de tiers, mandataires dynamiques et d'autres classes générées lors de l'exécution et ainsi de suite. Ainsi, le système d'exécution doit inclure un interpréteur de bytecode Java et / ou un compilateur JIT.