Unable to create vw_jni.lib in ubuntu 14.04 jessie/sid

[ravisharma4cloud]

Followed this step [](https://github.com/JohnLangford/vowpal_wabbit) for ubuntu. Unable to create vw_jni lib; Getting unsatisfied link error for the same.

java.lang.Exception <java.lang.UnsatisfiedLinkError: no vw_jni in java.library.path> is a java.lang.UnsatisfiedLinkError

Stacktrace was: java.lang.UnsatisfiedLinkError: no vw_jni in java.library.path

   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)

   at java.lang.Runtime.loadLibrary0(Runtime.java:870)

   at java.lang.System.loadLibrary(System.java:1122)

   at vowpalWabbit.jni.NativeUtils.loadOSDependentLibrary(NativeUtils.java:149)

   at vowpalWabbit.learner.VWLearners.loadNativeLibrary(VWLearners.java:88)

   at vowpalWabbit.learner.VWLearners.initializeVWJni(VWLearners.java:76)

   at vowpalWabbit.learner.VWLearners.create(VWLearners.java:44)

   at vowpalWabbit.learner.VWLearnersTest.testOldModel(VWLearnersTest.java:55)

   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

   at java.lang.reflect.Method.invoke(Method.java:498)

   at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)

   at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)

   at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:168)

   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)

   at org.junit.rules.RunRules.evaluate(RunRules.java:20)

   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)

   at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)

   at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)

   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)

   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)

[girnara]

I am facing the same issue. It was working perfectly fine with Mac OS. But when I have deployed it on ubuntu, it was not able to create vw_jni.lib library.
+1

[JohnLangford]

@jmorra @deaktator Any ideas?

[jon-morra-zefr]

Yes. The JNI layer is pretty brittle right now. I'd like to rewrite it in total, but that'll have to wait for a little bit. In the meantime here is what I suggest.

If you look here and here you'll see how we guess your OS. Basically if you run lsb_release -a and lsb_release -i and don't have something that matches what is in build.sh or is Scientific.6 then you're on your own for loading the native libraries.

There are two approaches for loading the native libraries yourself.

1. Call System.load(...) or System.loadLibrary(...) on the correct .so file that you build BEFORE executing any VW commands within Java.
2. Create a file called libvw_jni.so and place it on your LD_LIBRARY_PATH

If you need more help send me the output of running lsb_release -a and lsb_release -i and I can help you figure it out.

[raouf-aghrout]

Is there any plan to publish a vw-jni jar for 8.3.0 / 8.3.1?

[jon-morra-zefr]

It's on my roadmap to pick up but honestly I would rather invest time in getting a better deployment system across the board. If we have reliable packaging on Linux, OSX, and Windows then the Java layer will be truly machine agnostic. If anyone out there wants to contribute a true release process that would be very helpful as I'm not sure when I'll have time to work on it.

In the meantime I can try and see if I can do a Java release in the next week or so. But in the meantime it's not hard to build it yourself following the instructions above.

[raouf-aghrout]

Thanks Jon, we're going down the route of building it ourselves and just continuing with the use of 8.1 for now.

It would be good to know your vision for the deployment process you mentioned, I'd be happy to collaborate.

[jon-morra-zefr]

If the entire project had a deployment methodology across yum, apt-get, brew, and some Windows thing (I don't know what that is) then the Maven deployment is trivial. We can remove all the code in the java/src/main/bin directory and instead rely on consistent versioning across the native code and the Java code. We'd have to modify the Makefile in the java directory to make sure the generated library is placed in the appropriate system dependent location. Then Java's System.loadLibrary() would function correctly.

[jon-morra-zefr]

I've started to address this through #1193. At this point it's still a work in progress so I'd love feedback.

[JohnLangford]

I believe this is addressed in the master branch now.

[matanox]

I'm getting the same error on both Ubuntu 16.04 and CentOS 6.9, using a very recent build of VW. It seems that one must use make install for the runtime/JVM to be able to load the .so file of VW from the file system; it's not enough that it is stashed inside VW's JNI jar, or at least so in my setup.

There is probably some environment variable that could point the runtime/JVM at the .so file on disk, but a couple of hours sieving through the internet doesn't yield it for me. If you're using JNI, do yourself a favor and run make install, even if you'd otherwise not go for global installation.