* Mikolaj Izdebski: > On Fri, Oct 8, 2021 at 1:23 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: >> >> * Mikolaj Izdebski: >> >> > I want to propose updating Java Packaging Guidelines [1] to allow >> > installation of JNI shared objects in %{_prefix}/lib/%{name} or in >> > %{_libdir}/%{name}, according to packager preference. >> > >> > %{_libdir} expands to either /usr/lib or /usr/lib64 (depending on >> > system architecture), while %{_prefix}/lib always expands to /usr/lib. >> > To see what %{_libdir} expands to on each platform, you can run: grep >> > %_libdir -r /usr/lib/rpm/platform/ >> >> Isn't this a consequence of using absolute paths for JNI loading? >> >> The issue goes away if the system default or OpenJDK default paths are >> used. Neither of these paths include %{name}, of course. > > JNI shared objects are internal DSOs, which are expected to be loaded > and called only by corresponding Java bytecode. As such they should be > placed outside of dynamic linker search path, in a subdirectory called > %{name}. OpenJDK does not have code to load such DSOs. I believe OpenJDK as packaged for Fedora tries to load from /usr/java/packages/lib. Unfortunately, this path has been somewhat unstable (1.8.0 used /usr/java/packages/lib/amd64, it seems, and I've also seen /usr/lib/jni and other variants), but that should not matter for current Fedora Java packaging because 11 and 17 use the same path. Furthermore, in the current glibc implementation, private shared objects do not really exist because the dynamic loader tries too hard to avoid loading objects with the same soname. So even if the JVM tries to partition the C symbol namespace with RTLD_LOCAL on a per-class-loader basis, I doubt that this enables conflicting JNI libraries. >> > Since Maven is a noarch package, the symlink must technically point to >> > one fixed location, but libjansi.so ought to be installed in different >> > locations on different architectures. >> >> This also suggests a different problem: Why does Maven as a noarch >> package even have to know that libjansi.so exists? A future version of >> jansi could very well be noarch. I suspect it's related to dependencies >> bubbling up to consumers (which is related to the Class-Path: attribute >> ban). > > This is the way Maven is distributed and installed in binary form - > with all dependencies bundled in a single directory tree. That makes sense for installing things from a ZIP file, without a package manager. > Fedora maven package needs to recreate this directory structure, but > separate native code from Java bytecode. Symbolic links are used to > achieve this split. And indeed, the latest Maven 3.8.3 (not yet in > Fedora) does not include libjansi for Linux, only for Windows. Why do Fedora packages have to do this? I thought that Maven does not come with a module system. I think it should be possible to use consistent JAR names, do away with the symbolic links, and rely on the Class-Path attribute for linking. Doesn't Debian already do this? _______________________________________________ java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/java-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure