Linux controller plugin not architecture aware

Engines, Libraries and Tools JInput
#1

The linux controller plugins depend only on kernel features and I wonder why there are no architecture specific builds?

At least linux architectures with a working JRE 1.4 should be considered: sparc, i386, ia64, x84_64, ppc (late 2004)

(The same topic applies for Windows where you will soon have x86, x86_64 and ia64!)

Oh and interesting thing: Linux JRE reports the intel architecture as i386 while the Windows JRE says x86 …

#2

Hi
The source is freely available, and especially on linux, you just type ant to compile it all, it’s simple. I don’t have the hardware to test and binary builds on except my i686 box, and there is no point doing builds unless you can test them. ia64 and x86_64 will run the i386 binary as happily as the i686 will (just optimisations), sparc and ppc linux are unknown to me when it comes to running other binaries. again, under windows, they will all run the x86 binary.

So maybe sparc and ppc linux builds will be needed, but right now no-one has asked for them, and the code is freely available.

Thats just my view, GTG might disagree though :slight_smile:

Endolf

#3

x86 binaries can be run from x86_64 and ia64 but I wonder if webstart knows about that.

Will a ia64/x86_64 webstart accept these JNLP entries?


<resources os="Linux" arch="i386">
    <nativelib href="jogl-natives-linux.jar"/>
</resources>
#4

Probably not, but this would probably be an easy workround:

Kev

#5

Hi
I doubt it, but as has been pointed out in this thread there is some ambiguity about the need for the arch attribute. I can see that for linux it is needed as sparc and ppc client might not work with i386 binaries, but I’ve had no reports of anyone even trying. For now I might update my webstart to check for i386 under linux, but with no builds and no volunteers with the hardware to build and test, we can’t do the builds anyway. If you have ia64 or x86_64 access you could try the i386 binaries and/or compile from source and upload the binary somewhere.
I have no idea what will happen under windows, it may be that ia64 and x86_64 will run the x86 lib quite happily, in which case it probably doesn’t need the arch flag at all.
I have no clue how OSX handles this or even if there are different options on the mac for arch type.

I believe that you can do something like

<resources os="Linux" arch="i386" arch="ia64" arch="x84_64"> 
    <nativelib href="jogl-natives-linux.jar"/> 
</resources>

to load the same archive for any arch that matches. I’ve not got time or the hardware to test that right now though.

HTH

Endolf

Edit: Kev posted whilst I was so I didn’t see his post, but that would work too.

#6

I have a feeling that multiple “arch” attributes would be invalid in XML (but I can’t think why I think this ;))

Kev

#7

Your right, but

<resources os="Linux" arch="i386 ia64 x84_64">  
    <nativelib href="jogl-natives-linux.jar"/>  
</resources>

should work, take a look at the jinput.jnlp here (New Dawn Software) as that now has x86_64 in it for windows, with just the x86_64 in there jinput fails to find any devices in this box, with both in there, it finds it.

Hope that works :slight_smile:

Endolf

#8

Being pedantic as normal…

The JNLP spec actually says that architectures in the “arch” tag should be seperated by spaces. Each of the space seperated values are compared to the system property “os.arch”, if the value is a prefix then the resource is accepted.

Haven’t checked, but I suspect the reason your windows one works is because x86 is the last value. If you were to do “x86, x86_64” is probably wouldn’t.

Although, I note JWS is a little more loose with the spec :slight_smile:

Kev

#9

Yup, updated the JNLP in newdawn site and the post above, ta :slight_smile:

Endolf