Bug#734599: libsnappy-java: Fails with FAILED_TO_LOAD_NATIVE_LIBRARY
snappy-java doesn't build its JNI bindings. SnappyNative.cpp should be compiled as a libsnappyjava.so shared library and installed in a libsnappy-java package. The missing maxCompressedLength method reported by Oliver is actually defined in SnappyNative.cpp. I'll prepare an update with these changes. Any objection to move the Git repository under pkg-java? Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734599: libsnappy-java: Fails with FAILED_TO_LOAD_NATIVE_LIBRARY
Le Tue Nov 25 2014 at 3:29:13 PM, Emmanuel Bourg ebo...@apache.org a écrit : snappy-java doesn't build its JNI bindings. SnappyNative.cpp should be compiled as a libsnappyjava.so shared library and installed in a libsnappy-java package. The missing maxCompressedLength method reported by Oliver is actually defined in SnappyNative.cpp. I'll prepare an update with these changes. Any objection to move the Git repository under pkg-java? for me this is fine, this package is not specific to our fields. Emmanuel Bourg
Bug#734599: libsnappy-java: Fails with FAILED_TO_LOAD_NATIVE_LIBRARY
Hi again Alexandros, as I said two monthes ago: Your patch does not apply. I checked again and it turns out that the problem that it contains a patch for a non-existing Makefile.in - how did you got this file. We'd happily fix this bug but for me it is hard to reproduce (since I do not use this package) and your patch simply does not apply so I have no idea how I can help you. Kind regards Andreas. On Tue, Jan 21, 2014 at 05:05:50PM +0100, Andreas Tille wrote: Hi Alexandros, thanks for the patch to the problem report. I tried to apply this to the status of the corresponding Git repository git://git.debian.org/git/debian-med/snappy-java.git It seems you did not created the patch against this repository since it also contained an empty debian/patches/series file and a debian/source/format file. After dealing with some warnings the essential patch seems to be in debian/patches/jni.patch Unfortunately if I put this at the end of the series file it does not apply cleanly. Would you be so kind to rework your patch to apply cleanly with quilt? Your help is greatly appreciated since we simply have created the package as some precondition without the necessary solid Java background. Kind regards Andreas. -- http://fam-tille.de -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734599: libsnappy-java: Fails with FAILED_TO_LOAD_NATIVE_LIBRARY
Hello Andreas, I am sorry, I somehow missed the first correspondence, thanks for contacting me directly (I was actually beginning to lose hope). I will have a look at it ASAP On Fri, Mar 21, 2014 at 3:45 PM, Andreas Tille ti...@debian.org wrote: Hi again Alexandros, as I said two monthes ago: Your patch does not apply. I checked again and it turns out that the problem that it contains a patch for a non-existing Makefile.in - how did you got this file. We'd happily fix this bug but for me it is hard to reproduce (since I do not use this package) and your patch simply does not apply so I have no idea how I can help you. Kind regards Andreas. On Tue, Jan 21, 2014 at 05:05:50PM +0100, Andreas Tille wrote: Hi Alexandros, thanks for the patch to the problem report. I tried to apply this to the status of the corresponding Git repository git://git.debian.org/git/debian-med/snappy-java.git It seems you did not created the patch against this repository since it also contained an empty debian/patches/series file and a debian/source/format file. After dealing with some warnings the essential patch seems to be in debian/patches/jni.patch Unfortunately if I put this at the end of the series file it does not apply cleanly. Would you be so kind to rework your patch to apply cleanly with quilt? Your help is greatly appreciated since we simply have created the package as some precondition without the necessary solid Java background. Kind regards Andreas. -- http://fam-tille.de -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734599: libsnappy-java: Fails with FAILED_TO_LOAD_NATIVE_LIBRARY
Hi Alexandros, thanks for the patch to the problem report. I tried to apply this to the status of the corresponding Git repository git://git.debian.org/git/debian-med/snappy-java.git It seems you did not created the patch against this repository since it also contained an empty debian/patches/series file and a debian/source/format file. After dealing with some warnings the essential patch seems to be in debian/patches/jni.patch Unfortunately if I put this at the end of the series file it does not apply cleanly. Would you be so kind to rework your patch to apply cleanly with quilt? Your help is greatly appreciated since we simply have created the package as some precondition without the necessary solid Java background. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734599: libsnappy-java: Fails with FAILED_TO_LOAD_NATIVE_LIBRARY
Package: libsnappy-java
Version: 1.0.4.1~dfsg-1
Severity: grave
Tags: patch
Justification: renders package unusable
Dear Maintainer,
Apologies if this the wrong package to open a bug against, I was unsure whether
I should open it against libsnappy-java or libsnappy1, feel free to
reassign it if needed
While trying to use the simple example from the snappy-java documentation
attached below I encountered an error of FAILED_LOAD_NATIVE_LIBRARY. After a
lot of reading it seems like the upstream ships compiled versions of shared
object (.so) files for various OSes and architectures that get included in the
shipped jar file. Those are stripped out in the Debian package and a dependency
to the libsnappy1 package is declared. That is a nice approach IMHO
However, the .so file shipped by the libsnappy1 package
(/usr/lib/libsnappy.so.1.1.3) does not contain the necessary JNI bindings and
as a result the JNI calls from the Java code fail.
I have managed to bypass the problem by recompiling the libsnappy1 package
with the JNI bindings provided in the libsnappy-java package. I attach the
patch. I am not sure however if this is the best possible solution. It is
however a relatively clean one. Of course this solution is against the
libsnappy1 package and not the libsnappy-java package
Reproduce with:
SnappyTests.java:
import org.xerial.snappy.Snappy;
import java.lang.String;
import java.lang.System;
import java.io.IOException;
import java.io.UnsupportedEncodingException;
class SnappyTests {
public static void main(String[] args) throws
UnsupportedEncodingException, IOException {
String input = Hello snappy-java! Snappy-java is a JNI-based wrapper of
+ Snappy, a fast compresser/decompresser.;
byte[] compressed = Snappy.compress(input.getBytes(UTF-8));
byte[] uncompressed = Snappy.uncompress(compressed);
String result = new String(uncompressed, UTF-8);
System.out.println(result);
}
}
Compile with:
javac -cp /usr/share/java/snappy-java.jar SnappyTests.java
Run with:
java -cp '/usr/share/java/snappy-java.jar:.' SnappyTests
Stacktrace returned is:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:317)
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:219)
at org.xerial.snappy.Snappy.clinit(Snappy.java:44)
at SnappyTests.main(SnappyTests.java:11)
Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1856)
at java.lang.Runtime.loadLibrary0(Runtime.java:845)
at java.lang.System.loadLibrary(System.java:1084)
at org.xerial.snappy.SnappyNativeLoader.loadLibrary(SnappyNativeLoader.java:52)
... 8 more
Exception in thread main org.xerial.snappy.SnappyError:
[FAILED_TO_LOAD_NATIVE_LIBRARY] null
at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:229)
at org.xerial.snappy.Snappy.clinit(Snappy.java:44)
at SnappyTests.main(SnappyTests.java:11)
-- System Information:
Debian Release: 7.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.11-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -urN b/snappy-1.0.4/debian/libsnappy1.links a/snappy-1.0.4/debian/libsnappy1.links
--- b/snappy-1.0.4/debian/libsnappy1.links 1970-01-01 00:00:00.0 +
+++ a/snappy-1.0.4/debian/libsnappy1.links 2013-11-06 14:47:02.701611660 +
@@ -0,0 +1 @@
+usr/lib/libsnappy.so.1 usr/lib/libsnappyjava.so
diff -urN b/snappy-1.0.4/debian/patches/jni.patch a/snappy-1.0.4/debian/patches/jni.patch
--- b/snappy-1.0.4/debian/patches/jni.patch 1970-01-01 00:00:00.0 +
+++ a/snappy-1.0.4/debian/patches/jni.patch 2013-11-06 14:39:55.093530261 +
@@ -0,0 +1,411 @@
+--- /dev/null 2013-05-23 22:06:22.347926853 +
b/SnappyNative.cc 2013-11-06 12:27:53.491596706 +
+@@ -0,0 +1,237 @@
++/*--
++ * Copyright 2011 Taro L. Saito
++ *
++ * Licensed under the Apache License, Version 2.0 (the License);
++ * you may not use this file except in compliance with the License.
++ * You may obtain a copy of the License at
++ *
++ * http://www.apache.org/licenses/LICENSE-2.0
++ *
++ * Unless required by applicable law or agreed to in writing, software
++ * distributed under the License is distributed on an AS IS BASIS,
++ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
++ * See the License for the specific language governing permissions and
++ * limitations under the License.
++
