Spec URL: https://fedorapeople.org/~mkoncek/zstd-jni/zstd-jni.spec SRPM URL: https://fedorapeople.org/~mkoncek/zstd-jni/zstd-jni-1.5.2.3-1.fc37.src.rpm Description: JNI bindings for Zstd native library that provides fast and high compression lossless algorithm for Android, Java and all JVM languages. It features: * static compress/decompress methods * implementation of InputStream and OutputStream for transparent compression of data streams fully compatible with the "zstd" program. * minimal performance overhead Fedora Account System Username: mkoncek Having this package in Fedora would allow it to be used as a runtime dependency of apache-commons-compress. Note that upstream bundles zstd sources. I unbundle them but still bundle the zstd sources present in Fedora. Bundling is necessary because these binding depend on internal headers of zstd which are not provided by zstd-devel package. This package installs an internal shared library into fixed path at /usr/lib/zstd-jni because it does not make sense to have it installed as multilib.
Afaik the .so should be in /usr/libexec/ not in /usr/lib But I can not pickup review for one more week
or maybe %{_jnidir} ..how can anybody say it is easy to pacak java applications fo fedora.
echo 'System.out.println(System.getProperty("java.library.path"))' | jshell - /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib Is killing all waht I said.
I believe JNI shared objects can be installed into /usr/lib. See: https://pagure.io/fesco/issue/961 And one of our bugfixes: https://bugzilla.redhat.com/show_bug.cgi?id=1994935 With pull requests: https://src.fedoraproject.org/rpms/jansi/pull-request/7 https://src.fedoraproject.org/rpms/maven/pull-request/29
According to https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#JNI The approach I usually follow is: - Install *.so into %{_libdir}/<upstreamLibname>.so - Install *.jar file using *.so into /usr/lib/java, which should be the default if %mvn_install is being used.
java.library.path includes /usr/lib and /usr/lib64 depending on the architecture. Thus, 'System.loadLibrary("upstream-name")' should work out of the box. $ java -XshowSettings:properties -version 2>&1 | grep -C5 java.library.path java.awt.printerjob = sun.print.PSPrinterJob java.class.path = java.class.version = 55.0 java.home = /usr/lib/jvm/java-11-openjdk-11.0.15.0.10-1.fc35.x86_64 java.io.tmpdir = /tmp java.library.path = /usr/java/packages/lib /usr/lib64 /lib64 /lib /usr/lib java.runtime.name = OpenJDK Runtime Environment While /usr/lib/<name> works too, it requires more patching.
I indeed wanted to install the .so into /usr/lib/<name> because it is a package-private file. Hardcoded /usr/lib/<name> is simpler to patch than %{_libdir}/<name> whichrequires iterating over library path, appending the package name and detecting if the file exists.
(In reply to Marián Konček from comment #7) > I indeed wanted to install the .so into /usr/lib/<name> because it is a > package-private file. Hardcoded /usr/lib/<name> is simpler to patch than > %{_libdir}/<name> whichrequires iterating over library path, appending the > package name and detecting if the file exists. Be my guest. Note that I said to install into %{_libdir}. I.e. %{_libdir}/libfoo.so. Perhaps with a symlink to it from %{_libdir}/<name>/*.so The packaging guidelines are not great on that matter, imo.
I know, but I specifically wanted to avoid plain %{_libdir} for the "private shared object" reason. I updated the .spec and .srpm to install the .jar into /usr/lib/java.
Simple way to check if the code finds the native library: $ jshell --class-path <.../zstd-jni....jar> var cls = Class.forName("com.github.luben.zstd.util.Native") cls.getMethod("load").invoke(null) cls.getMethod("isLoaded").invoke(null)
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted.
I changed my mind and decided that this package is not needed in Fedora as a dependency. Closing the issue.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days