Locating libfuse more reliably #124
Description
First off, thanks for the great library. I have already got a working file system based on it, and so far it's been flawless. I thoroughly approve of the no/low dependencies approach :)
However, like other FFM API libraries I have worked with, it seems a bit hit-or-miss as to whether FFM will actually find the library out of the box. So this will often mean adding a java.library.path .
In the case of jfuse on my chosen development environment (Linux Mint), and despite libfuse3 being installed from the standard repositories (to /lib/x86_64-linux-gnu), the library path needed is ..
-Djava.library.path=/lib/x86_64-linux-gnu:/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib
Why Java+FFM cannot find these itself is beyond me. Lots of other applications seem to locate libraries just fine! In my experience the situation is worse on Mac OS, particular when trying to link to standard libraries such as libc in "frameworks".
When I hit this problem in another project, I realised I had never seen this problem before when using JNA. It tends to just work and always locates the wanted library. The JNA project have been doing this for years, so I basically used their expertise and extracted the bits from JNA that deal with locating and loading libraries and used that to load for FFM.
This worked well, even to the extent the library bundling works (just put pre-compiled shared libraries in the resource path). And after having needed this a few times, I created a little library for it, NIH. I am not suggesting you use this directly, but the answer is in there, and the license is compatible should you want to.