Hi, I am trying to set this up in ubuntu. Im fairly new to linux and I also hate setting up environments. When you say add the .so file to java.library.path - how exactly do I do that ?
PS Im using eclipse.
Easiest way in eclipse is to right click the jinput.jar library in your project settings, and point the native library to where the .so is. From the command line you’ll need a -Djava.library.path= pointing at the directory containing the .so
HTH
Endolf
As an alternative, all you have to do is copy the appropriate .so for your verrsion, i.e…
for 32 bit ubuntu: libjinput-linux.so
and for 64 bit ubuntu: libjinput-linux64.so
to the proper directory in your JRE installation. For example, on my laptop, I have the JDK installed in
/opt/jdk1.6.0_21/
so the appropriate directory is
/opt/jdk1.6.0_21/jre/lib/i386
all you have to do is copy the proper .so to that directory and you are ready to go.
hum really not a best practice idea, after some monthes you will have forgot that you put this library in a system folder and will encounter bugs in others projects and will have trouble to find where it come from ( caused by version mismatch between libraries and jars)
I agree with the potential for version skew. Perhaps I don’t understand the suggestions above.
Something has to bind the .so to a known place so that the java library can find the needed functions.
How do you suggest one do that?
Adding
-Djava.library.path=/path/to/your/additional/so/files
to the java command when starting an application expands the native library search path.
For linux “experts”: it’s more or less the same as doing
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/your/additional/so/files; java …
Both have the same effect, that the native libraries are found by the java executable without adding them to some system paths.
Thanks for the clarification. Nice to know.
I’m not convinced that its really needed, over the simple copy. Except that if you put it in the JRE directory, and subsequently use another JRE version or even change to a completely new JRE, you have to redo it. I don’t think its likely that we’ll see a lot of name conflict, libjinput-linux.so is a nice name.
Adding it to the jdk is crazy, what happens if you have 2 apps installed that depend on different versions of jinput?
[quote=“endolf,post:8,topic:35634”]
I could be wrong, I often am.
I can’t imagine that. Are there really serious compatibility problems with jinput? Does it really upgrade that frequently?
Standard Unix practice, going back decades, is to use version numbers in the name to keep them separate if needed.
libjinput-linux_2.1.3a.so
On Windows, we are stuck with DLL hell
People can do what ever they want with JInput code (with BSD limits), which means we can’t assume anything. And as you point out, windows is ‘fun’
Endolf