Document how to properly set the java.library.path

[mauromol]

On my Eclipse 2020-06 installed with flatpak I added Subclipse: https://github.com/subclipse/subclipse
This SVN plugin can use native JavaHL libraries installed on the local machine to provide SVN functionality.
In order to properly do this with my Linux Mint 18.3 (based on Ubuntu 16.04) I need to install WANdisco's libraries, because otherwise the JavaHL version provided by Ubuntu is too old, see: https://github.com/subclipse/subclipse/wiki/JavaHL-on-Linux

WANdisco's libraries are installed at /usr/lib/jni, which is not among the default paths checked by Subclipse. So, as documented in Subclipse's wiki, I have to add the following VM arg to eclipse.ini: -Djava.library.path=/usr/lib/jni.
Right now I'm changing /var/lib/flatpak/app/org.eclipse.Java/current/active/files/eclipse/eclipse.ini directly, although I'm not sure it's the best way to do this (see #14). Nevertheless, the change is correctly taken by Eclipse, but yet Subclipse says it can't find JavaHL libraries in /usr/lib/jni. Thinking about this a bit, I suspect it's due to the flatpak application being sandboxed.

So, how to fix this, if at all possible? Thanks.

[mauromol]

I've learnt about the /run/host... path seen by the Flatpak application in #5. So, I tried to set -Djava.library.path=/run/host/usr/lib/jni in eclipse.ini, but still getting an error from Subclipse:

Failed to load JavaHL Library.
These are the errors that were encountered:
no libsvnjavahl-1 in java.library.path: [/run/host/usr/lib/jni]
/run/host/usr/lib/jni/libsvnjavahl-1.so.0.0.0: libsvn_repos-1.so.1: impossibile aprire il file oggetto condiviso: File o directory non esistente
no svnjavahl in java.library.path: [/run/host/usr/lib/jni]
java.library.path = /run/host/usr/lib/jni

The error says in English: "cannot open the shared object file: non existing file or directory".

I'm not an expert here: perhaps libsvnjavahl-1.so.0.0.0 is trying to load libsvn_repos-1.so.1 whose real path is /usr/lib/libsvn_repos-1.so.1 and fails?

[mbooth101]

Sigh, it looks like WANdisco may be hard-coding the "rpath" in their binaries. This breaks dynamic loading in the Flatpak sandbox context. IMHO the dynamic linker is almost always smarter, so it's best not to try to outsmart it.

On Fedora and RHEL there is a tool called chrpath you can use to remove hard-coded rpaths from compiled binaries -- maybe it also exists on Ubuntu. You can try running this on all the WANdisco supplied library binaries:

$ chrpath --delete /path/to/so

Otherwise you could always try switching to the pure-Java SVNkit implementation of Subversion in the Subclipse preferences. It's a bit slower, but it should work fine.

In the long term, we could investigate bundling correctly built SVN binaries in the Flatpak sandbox.

[mauromol]

I'll try to have a look to chrpath, thank you. I'll report if I make progress. Meanwhile I think SVNkit is the way to go, although I always had mixed results with it.
Having SVN binaries in the Flatpak would be nice, although I suspect it will never happen due to licensing and things like that... Also, Subclipse is an Apache project and not an Eclipse project, while the Eclipse counterpart, Subversive, which I liked a lot more, has been abandoned for long :-(

[mauromol]

On Fedora and RHEL there is a tool called chrpath you can use to remove hard-coded rpaths from compiled binaries -- maybe it also exists on Ubuntu. You can try running this on all the WANdisco supplied library binaries:

$ chrpath --delete /path/to/so

For the records, I tried chrpath -l on /usr/lib/jni/libsvnjavahl-1.so.0.0.0 and on /usr/lib/libsvn_repos-1.so.1, but for both files I get: "no rpath or runpath tag found".

[mbooth101]

For the records, I tried chrpath -l on /usr/lib/jni/libsvnjavahl-1.so.0.0.0 and on /usr/lib/libsvn_repos-1.so.1, but for both files I get: "no rpath or runpath tag found".

Wait, on Ubuntu the libs are split between /usr/lib/jni and /usr/lib ??

You are adding only /run/host/usr/lib/jni to the java.library.path, but I assume you need both locations in this case.

[mauromol]

Honestly the situation is not very clear to me. WANdisco libraries are under /usr/lib/jni and with the standard Eclipse installation I just need to add that folder to java.library.path.

However, adding the corresponding path to the Flatpak version, it complains it can't find libsvn_repos-1.so.1, which I see is under /usr/lib in my system, so I suspect that the former is linked against the latter with an absolute path. This seems not to be a problem with the standard Eclipse package, while it is for the Flatpak version.

I just tried to also add /run/host/usr/lib to the java.library.path passed to the Flatpak version, but the error I get is the same:

[mbooth101]

Honestly the situation is not very clear to me. WANdisco libraries are under /usr/lib/jni and with the standard Eclipse installation I just need to add that folder to java.library.path.

Sure, because the dynamic linker will look in /usr/lib implicitly.

However, adding the corresponding path to the Flatpak version, it complains it can't find libsvn_repos-1.so.1, which I see is under /usr/lib in my system, so I suspect that the former is linked against the latter with an absolute path. This seems not to be a problem with the standard Eclipse package, while it is for the Flatpak version.

Right, that's why I suspected rpath use -- the filesystem root of the sandbox is not the same as the filesystem root of the host.

I just tried to also add /run/host/usr/lib to the java.library.path passed to the Flatpak version, but the error I get is the same:

I'm afraid I ran out of suggestions for now (except use the SVNkit implementation)