I obtain this now:
[quote]java.lang.UnsatisfiedLinkError: .java/deployment/cache/6.0/15/307218f-3999fd85-n/libjinput-linux64.so: /lib64/libc.so.6: version `GLIBC_2.7’ not found (required by .java/deployment/cache/6.0/15/307218f-3999fd85-n/libjinput-linux64.so)
[/quote]
Ok, so the version of glibc jinput was compiled against was 2.7 and you have a different version. Without statically linking the whole of glibc in to jinput, I’m not sure what can be done (I confess I’ve not explored thoroughly).
Any ideas?, otherwise you might have to compile jinput libs yourself. It’s one of the joys of linux as I understand it.
Endolf
Statically linking the whole glibc would solve my problem. I cannot compile JInput with each version of glibc. How are such things done in LWJGL? I don’t have such errors with LWJGL and JogAmp (JOGL, JOAL, JOCL, etc…).
It wouldn’t do any good for my bandwidth though 
I don’t know, feel free to find out and I’ll see what can be done with JInput, it might be as simple as some compiler/linker arguement(s), but I don’t know I’m afraid.
Endolf
JOGL 1.1.1a only contains about 1 and 2 MB, it doesn’t have such problems. I will ask some help to Sven. I assume there is a way to use a static link to a library without embedding it entirely.
Sven answered here:
http://forum.jogamp.org/Is-JogAmp-statically-linked-to-glibc-tp3218570p3218570.html
Hi
Ok, so they do the same as JInput does, the only difference is their build machine is still on an older version of libc. The build farm JInput uses is not exclusively for JInputs use, and I had to upgrade the distribution for another build. I will take a look at the possibility of rolling libc back, or installing an older version in parallel for building against, but I don’t know when I’ll have time to do this.
My best suggestion currently is for you to build the linux binaries on an old enough version of libc to cover your target user base. Users on newer version will still be fine on that.
Endolf