Trying to run on CentOS3

Subscribe to Trying to run on CentOS3 3 post(s), 2 voice(s)

 
Avatar (SF) Courtney 2 post(s)

I’ve been trying to get JBidWatcher to run on my CentOS 3.6 box for a while. I got it to run a while back, near when I first setup the box. But I wasn’t ready to use it then, and between CentOS updates, Jbidwatcher updates, and my experimenting, it’s been broken and I can’t get it to run.

I’ve followed the various instructions elsewhere, for running JBidWatcher on Linux, and it worked once, but now I always get a fatal exception error, and something about an invalid ELF header. I’ve been running Azureus just fine, (it’s the BitTorrent client that is probably similar to JBW in that it’s a large, standalone Java application) but it has a much more complicated startup script.

  1. /usr/java/jre1.5.0_06/bin/java -Xmx512m -Xms256m -jar JBidWatcher-1.0pre5.jar
    resource == null
    Exception in thread “main” java.lang.UnsatisfiedLinkError: /usr/java/jre1.5.0_06/lib/i386/xawt/libmawt.so: /usr/java/jre1.5.0_06/lib/i386/xawt/libmawt.so: invalid ELF header
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.loadLibrary0(Unknown Source)
    at java.lang.System.loadLibrary(Unknown Source)
    at sun.security.action.LoadLibraryAction.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.Toolkit.loadLibraries(Unknown Source)
    at java.awt.Toolkit.(Unknown Source)
    at java.awt.Color.(Unknown Source)
    at javax.swing.plaf.metal.MetalTheme.(Unknown Source)
    at javax.swing.plaf.metal.MetalLookAndFeel.getCurrentTheme(Unknown Source)
    at javax.swing.plaf.metal.MetalLookAndFeel.createDefaultTheme(Unknown Source)
    at javax.swing.plaf.metal.MetalLookAndFeel.getDefaults(Unknown Source)
    at javax.swing.UIManager.setLookAndFeel(Unknown Source)
    at javax.swing.UIManager.setLookAndFeel(Unknown Source)
    at javax.swing.UIManager.initializeDefaultLAF(Unknown Source)
    at javax.swing.UIManager.initialize(Unknown Source)
    at javax.swing.UIManager.maybeInitialize(Unknown Source)
    at javax.swing.UIManager.getInstalledLookAndFeels(Unknown Source)
    at JBidWatch.main(JBidWatch.java:606)

Anyways, if anyone could point me in the right direction to track down the cause of this error that would be very helpful.

 
Avatar Morgan Schweers Administrator 1,204 post(s)

Greetings,
I’m going to bet that Azureus works because it’s using SWT (a different windowing toolkit) as its UI and Look&Feel, whereas JBidwatcher tries to use the ‘platform preferred’ look&feel under Swing/AWT.

This is reinforced by the line 606 in JBidwatch.main referred to in the exception, which is a call to UIManager.getInstalledLookAndFeels().

At the top of the exception (the place it actually failed) is a failure to load a file from the Java libraries, because it appears corrupt. My first suggestion would be to delete the current Java 5 install, and download and reinstall the Java 5 package, preferrably from Sun directly.

I hope that helps!

— Morgan Schweers, CyberFOX!

 
Avatar (SF) Courtney 2 post(s)

Yep… the corrupted java files was the issue that was causing me problems. I reinstalled the Java rpm, and Jbidwatcher works now.

Yes, Azureus does use SWT, so that was why it was still working.