RXTX native library unter Linux in jar build angeben

  • Themenstarter Themenstarter Gast2
  • Beginndatum Beginndatum
G

Gast2

Gast
Hi Leute,

bin gerade dabei meine Software auch unter Linux zum laufen zu bringen. Naj aim Prinzip läufts komplett bis auf den build.

In der IDE (Eclipse) habe ich natürlich die native libary für RXTX im classpath des projekts angegeben. Funktioniert prima. Wenn cih aber nun das ganze über mein ant skript builde findet er die *.so nicht. Hatte angenommen, dass es wie bei Windows reicht diese neben die executable jar zu legen (Unter windows natürlich die dll).

Die .so soll in jedem Fall nicht irgendwohin kopiert werden, sondern lokal bei den anderen files der Software liegen!

Ich finde einfach nicht, wie ich im manifest der executable jar angeben kannm, dass sich die *so neben der jar liegt.

Der Fehler ist natürlich, dass die native library nicht in java.library.path gefunden werden kann. Klar da ist sie ja auch nicht und soll sie nicht hin.

Ich hoffe jemand kann mir helfen ...
 
Scheint so zu sein, dass man java.library.path tatsächlich nur über die commandline setzen kann. Habe keine Möglichkeit gefunden das übers manifest im jar mitzugeben.

Schade.
 
Dein Weg führt dich knallhart durch den Dschungel Reflection...
Java:
import java.io.File;
import java.lang.reflect.Field;
import java.security.AccessController;
import java.security.PrivilegedAction;

public final class Distributable
{
	public static void main(String[] args)
	{
		try {
			System.loadLibrary("libjssc");
			System.out.println("libjssc found in java.library.path");
		} catch(Throwable e) {
			System.out.println("libjssc not found in java.library.path");
		}
		AccessController.doPrivileged(new PrivilegedAction<Void>()
		{
			public Void run()
			{
				try {
					String lib = ("32".equalsIgnoreCase(System.getProperty("sun.arch.data.model", "32")))? "i386" : "amd64";
					Field usrPathsField = ClassLoader.class.getDeclaredField("usr_paths");
					usrPathsField.setAccessible(true);
					String[] user_paths = (String[]) usrPathsField.get(null);
					String[] new_user_paths = new String[user_paths.length + 2];
					System.arraycopy(user_paths, 0, new_user_paths, 0, user_paths.length);
					new_user_paths[user_paths.length    ] = new File("lib").getAbsoluteFile().toString() + File.separator;
					new_user_paths[user_paths.length + 1] = new_user_paths[user_paths.length] + lib + File.separator;
					for(int n = 0; n < new_user_paths.length; n++) {
						System.out.println(new_user_paths[n]);
					}
					usrPathsField.set(null, new_user_paths);
					usrPathsField.setAccessible(false);
					System.out.println("System ok");
				} catch(Throwable e) {
					System.out.println("System ****ed");
				}
				return null;
			}
		});
		try {
			System.loadLibrary("libjssc");
			System.out.println("libjssc found in java.library.path");
		} catch(Throwable e) {
			System.out.println("libjssc not found in java.library.path");
			e.printStackTrace();
		}
	}
}
Dieses hatte ich mal zum experimentieren geschrieben... das Ganze sollte irgendwann auch mal bei unsignierten Applets funktionieren, aber soweit ging es dann doch nicht. Die PrivilegedAction kann also glaub' ich wieder entfernt werden. Des Build mit Ant dürfte aber weiterhin fehlschlagen, da der Pfad erst zur Laufzeit geändert wird.
 
Meine Güte, ist das so exotisch eine native library zu benötigen?

Schreibe dann lieber ein kleines Startskript, welches per command line den java.library.path setzt ...
 
Schreibt ein Skript start.sh mit folgendem Inhalt im gleichen Verzeichnis wie die jar und packt die *.so files ins lib Verzeichnis:

Code:
java -Djava.library.path='./lib' -jar LoopMaster.jar
 

Zurück
Oben