Attempting to load liblibfuse.so.2.so about jnr-fuse HOT 8 OPEN

Hey, @overheadhunter!

Thanks for noticing, I'll take a look into this. Interestingly, it works well on CI without any issues.

from jnr-fuse.

I think, one of the possible explanations is that jnr used to fail to "identify" the OS, so the switch would fall through to the default section.

from jnr-fuse.

Possibly. We distribute our software as an Appimage which has some different environment variables that might cause the app to use the default branch of that switch-statement... 🤔

from jnr-fuse.

Hey, @overheadhunter! From looking at https://github.com/jnr/jnr-ffi/blob/master/src/main/java/jnr/ffi/provider/jffi/NativeLibrary.java#L79, it seems like the first call should be end up calling dlopen("libfuse.so.2"). Do you know what can be the reason for this call to fail?

I'll add a fallback call to try fuse anyways since there is a possibility that one of them fails.

from jnr-fuse.

@overheadhunter As a quick workaround, you could try something like the following with the current version:

LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/full/path/to/libfuse.so.2" java -cp ...

from jnr-fuse.

Hey, @overheadhunter! Could you verify the fix from master? If it fixes the issue, I can publish a new version.

from jnr-fuse.

it seems like the first call should be end up calling dlopen("libfuse.so.2").

But this assumes that libfuse.so.2 is in the current working directory, correct? Only the second...nth attempt to dlopen the lib try it with an absolute path.

I will do some experiments with both, the LD_LIBRARY_PATH as well as the master branch on Wednesday.

from jnr-fuse.

I just started my debugger with a breakpoint in this line and found out that files inside /lib/x86_64-linux-gnu such as libfuse.so.2 are missing while other files such as libdrm_tegra.so.0.0.0 are listed even if they do not exist.

This lead me to the assumption that /lib/x86_64-linux-gnu is somehow different due to Flatpak's sandbox (I'm running the Flatpak version of IntelliJ here - and we plan to distribute our application as a Flatpak itself, too).

Playing around with LD_LIBRARY_PATH as well as java.library.path does help locating libfuse. However, fuse mount fails. Maybe due to missing transitive .so dependencies..?

fuse_main_real returns 1:

Caused by: ru.serce.jnrfuse.FuseException: Unable to mount FS, return code = 1
	at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:277)

I cloned your repo and built 0.5.4-SNAPSHOT. Behaviour is unchanged. I set a breakpoint here and could see that this branch the fallback routine was triggered but threw an UnsatisfiedLinkError itself.

Sadly the fix doesn't help. That doesn't mean that you should rollback you change, at least it will now construct the correct regex. Also, I verified that it works correctly on non-Flatpak environments.

I believe the root cause is somewhere else. Feel free to close this issue, as I have a feeling there is nothing you can do about it as long as fuse doesn't work inside Flatpak's sandbox...

from jnr-fuse.