Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attempting to load liblibfuse.so.2.so #81

Open
overheadhunter opened this issue Sep 4, 2019 · 8 comments
Open

Attempting to load liblibfuse.so.2.so #81

overheadhunter opened this issue Sep 4, 2019 · 8 comments
Assignees

Comments

@overheadhunter
Copy link
Contributor

overheadhunter commented Sep 4, 2019

I just noticed that the lib prefix as well as the .so suffix is appended twice when you attempt to load the fuse library on Linux here:

case LINUX:
libFuse = loader.load("libfuse.so.2");
break;

You pass in the full file name to jnr.ffi, which will then try to find a file named liblibfuse.so.2.so(.[0-9]+)?.

I think it is best to just invoke loader.load("fuse"); on Linux.

At the same time I'm wondering how it could have ever been working before (which it did). This doesn't make any sense to me.

Workaround: ln -s libfuse.so.2 liblibfuse.so.2.so not feasible for endusers, but helps me during development until this is fixed 😉

@SerCeMan
Copy link
Owner

SerCeMan commented Sep 4, 2019

Hey, @overheadhunter!

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

@SerCeMan SerCeMan self-assigned this Sep 4, 2019
@SerCeMan
Copy link
Owner

SerCeMan commented Sep 4, 2019

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.

@overheadhunter
Copy link
Contributor Author

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... 🤔

@SerCeMan
Copy link
Owner

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.

@SerCeMan
Copy link
Owner

SerCeMan commented Sep 15, 2019

@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 ...

@SerCeMan
Copy link
Owner

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

@overheadhunter
Copy link
Contributor Author

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.

@overheadhunter
Copy link
Contributor Author

overheadhunter commented Sep 18, 2019

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants