Only O_RDWR is set, but MumbleLink.[uid] does not exist, causing shm_open to fail terribly since it's not told to create the shm if not present.

In connection with #8 and the fact your 32-bit binary seems to be the outdated one after all, I managed to patch it by hand in the 64-bit binary: replace "BE 02 00 00 00" with "BE 02 01 00 00"

The current code is mainly only copied and refactored from the Mumble Wiki. This I will have to make sure is fixed with adding | O_CREAT in the new mumble-LinkAPI.

Next version will use jna/LinkAPILibrary.java and the natives coming from there.

This is also what was causing a lot of strange issues with MumbleLink not working on Linux. The 64-bit Linux fix could presumably be applied soon.

This sounds like always starting Mumble before Minecraft could be a workaround for now.

Due to the complicated nature of gradle, forgegrade, fml and mumble-LinkAPI all having changed over the time the next update is going to be quite a load of work for me.

It is not a workaround. O_CREAT is necessary to create a new shared memory
object, so it will fail every time as you're always the side creating it.

2016-01-23 0:53 GMT+01:00 zsawyer [email protected]:

This sounds like always starting Mumble before Minecraft could be a
workaround for now.

Due to the complicated nature of gradle, forgegrade, fml and
mumble-LinkAPI all having changed over the time the next update is going to
be quite a load of work for me.

—
Reply to this email directly or view it on GitHub
#9 (comment).

That is not true otherwise it would have never worked for me but it was tested on ubuntu in early stages.
https://github.com/mumble-voip/mumble/blob/master/plugins/link/link-posix.cpp#L177

From what I know, glibc changed this sometime during its lifetime, as I know it worked for some Linux users but not others. However, O_CREAT is necessary as per the standards/documentation anyway.

Also, any news on this?

depends on zsawyer/mumble-LinkAPI#5

Is this mod still being worked on?

Is this mod still being worked on?

Yes. If time permits.

Hey, I am trying to use this mod on linux together with the flatpak version of Mumble. I cann't get the connection to work. I am wondering if it is a flatpak issue or if it is the issue described in this issue. any idea how I could investigate that? I assume I should be seeing files generated in /dev/shm. I don't. So currently I think I am having the same issue with failing to create the shm.

Hey, I am trying to use this mod on linux together with the flatpak version of Mumble. I cann't get the connection to work. I am wondering if it is a flatpak issue or if it is the issue described in this issue. any idea how I could investigate that? I assume I should be seeing files generated in /dev/shm. I don't. So currently I think I am having the same issue with failing to create the shm.

Please look here:
https://github.com/zsawyer/MumbleLink#no-linking-when-using-flatpack-on-unix

It's flatpak...
The Mumble Link works via SHM and /dev/shm is by default sandboxed by Flatpak.

I have seen that. I have read that. Just like I have read this Issue. If asiekierka is correct with his comment but you being the side creating the objects (files?).

it is not a workaround. O_CREAT is necessary to create a new shared memory
object, so it will fail every time as you're always the side creating it.

then whatever or not the MUMBLE! is the flatpak version shouldn't matter when looking at /dev/shm. As the NOT-FLATPAK version of minecraft should be creating the "file(s)". Unless I missunderstood something. Based on your answer, I have to assume that you missunderstood me. Now let me be clear.

Mumble - flatpak version
Minecraft - standard version (using MultiMC as a Launcher)

that is different to your README.md, because in your README.md, Minecraft is the flatpak program.

I am by no means an expert. So, sorry if i am being an idiot.

Hey, I am trying to use this mod on linux together with the flatpak version of Mumble. I cann't get the connection to work. I am wondering if it is a flatpak issue or if it is the issue described in this issue. any idea how I could investigate that? I assume I should be seeing files generated in /dev/shm. I don't. So currently I think I am having the same issue with failing to create the shm.

Please look here:
https://github.com/zsawyer/MumbleLink#no-linking-when-using-flatpack-on-unix

It's flatpak...
The Mumble Link works via SHM and /dev/shm is by default sandboxed by Flatpak.

that is true. I am writing here because I cann't find the file in /dev/shm when minecraft is running (and I am on a server) and if my understanding is correct, I should see the file in /dev/shm because minecraft should be generating it. That is why I am writing here, I currently think that minecraft is failing in generating the shm file. I am not sure because I was unware of SHM beforehand. the mumble flatpak issue can be solved and addressed afterwards, if it exists. :D. THANKS to both of you!

The file needs to be written to by Minecraft and read by Mumble. So if either of them is sandboxed, they might be unable to see each other.

I understand you point. Minecraft should be at least able to initialize the shm.

Maybe this is a test case to verify that it indeed its an issue the the mod does/cannot create the shm.
It is possible that in my tests mumble simply always created the shm and everybody was happy.

Now regarding this particular flatpak scenario:
Mumble needs access to the shm so if mumble is running in a sandboxed environment it might not see it unless you specify the forwarding for mumble similarly how the faq suggests just on mumble.

This might also instantly solve your problem because it might be that mumble creates the shm instead of the mod.

Also: I am not sure if you should actually see the shm since it is not a normal file it is shared memory. You might need a special tool to see it. ipcs comes up on a quick Google search.

I have installed the "normal" mumble and it works now. i am sorry for the stress. but it seems to be the case that the mod cannot create the shm.