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. The Java
counterpart of particular JNI DSO typically contains specific code to
search for the DSO and load it.
A typical Java application is installed into a single directory tree
containing everything needed to run that application - Java bytecode,
native libraries, configuration files, data etc. Java applications
packaged as Fedora RPM packages install each of these into different
system directories - bytecode in /usr/share/java, native libraries in
/usr/lib or /usr/lib64, configuration files in /etc, data in /var and
so on. The single upstream directory is then created in
/usr/share/%{name}, but instead of regular files there are symbolic
links pointing to the actual location where the files are installed.
> > 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. 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.
--
Mikolaj Izdebski
_______________________________________________
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
