[SOLVED] Minecraft: Failed to locate library: liblwjgl.so

[statikregimen]

Hello,

For now, I'm getting by with https://gpo.zugaina.org/games-action/minecraft but it'd be nice to just download the game directly from Mojang for updates, rather than relying on someone else's time/effort, so hopefully I can solve this issue.

I'm struggling to find any relevant references about lwjgl in my searching so far...certainly no mention of a way to install it (or add support via USE flag, or whatever). Feels like one of those issues where I'm the only one in the world who's had this, yet somehow the above ebuild is working?

Any help is, as always, greatly appreciated!!

Here is the crash log, fwiw:

[Ant P.]

Where are you seeing 1.14? The official source says the latest is 19w11b, which the java launcher runs just fine.

[statikregimen]

Well, I'm a moron about the latest version... something in the minecraft wiki lead me to beleive 1.14 was released. Anyway, i see here, that it is still upcoming. My bad.

Nevertheless, that doesn't change nor solve my problem at all and I would still like to sort it.

[Ant P.]

lwjgl.so is supposed to be extracted from the game files at runtime, do you have /home mounted noexec?

[statikregimen]

Thanks for the replies

Home is mounted thusly, in fstab:

[Ant P.]

Doesn't look like a filesystem issue...I'm not sure what it could be. Does the file exist? Look in ~/.minecraft/versions/<ver>/ for a directory with "natives" in the name, you might need something like inotify-tools to catch it being written if it cleans up on crash though.

Alternatively, there's a lwjgl package in java-overlay that might work as a workaround.

[statikregimen]

I still have the game installed via the working overlay, mentioned above, so any files in ~/.minecraft have likely been created by that. I did not realize that directory existed, so I renamed it, to get it out of the way and tried again. This time it seemed to download a bunch of stuff, but still threw the same error in the end.

It predictably created a new ~/.minecraft/ and in versions/1.13.2/ there is a .jar and a .json file. I'm not familiar with inotify-tools, but will try to firgure it out when I get a chance. I will try the java-overlay as well.

THanks!

Edit:

I forgot to mention

[statikregimen]

This is an ongoing issue. The legacy launcher from the flussence overlay no longer works. It's too buggy to try installing other versions of the game (the UI doesn't refresh properly). But as of 1.14.3 or .4, it just hangs when I click "Play"...button changes to "Preparing" and nothing else happens until I force quit (it doesn't even seem to try to download anything).

I tried a newer launcher version from the trolltoo overlay, which is only working on only one of three machines, so far...the other two continue to complain about missing lgjwgl.

I've tried basically all the other overlays as well, as far as I know. Direct download from the official Minecraft website, has the same issue.

Thankfully, I no longer feel like the only person in the world. There is this recent official bug report. One other Gentoo user also replied to it, and mentioned a workaround but I have no idea what he means.

EDIT: I spoke to soon about the buggy UI above. I'm now trying to use the version from the java overlay (as opposed to flussence above), and this UI is much better so far.

EDIT2: Was successfully able add a new profile for 1.14.3 and game downloaded, then launched normally. I will investigate this odd behavior more....So far cannot get 1.14.4 to even download from the launcher available in the java overlay. And while it will download in newer launchers, it will not run due to apparently missing LGJGW.

EDIT3: I have no idea which overlay I'm using to make 1.14.3 work =/

[Ant P.]

Vanilla 1.6.91 launcher will download and run 1.14.3 fine for me.

With 1.14.4 it freezes with a "Preparing..." message, and I get this in the terminal:

[statikregimen]

[Satuya Lekany]

[statikregimen]

[Hu]

You probably had noexec there because you read a post from me, or someone who thinks like me, encouraging you to put it there. It is correct that it be there. The launcher is incorrect to think it can write code to /tmp and run it. Blocking that is a very common security policy going back years, if not more than a decade, whether implemented via a mount option or something more elaborate, because that is a very common early step in exploits.

Step 1: get just enough code execution to write the real payload somewhere. /tmp is a popular place to write the payload because it practically always exists and is practically always writable.
Step 2: write that payload, possibly downloaded from somewhere.
Step 3: execute that payload, which would typically be less constrained than the stage 1 payload. For example, the stage 1 may be limited in size to what would fit in a buffer overflow, or limited in content to what could pass through the victim's filters. The second payload is usually retrieved through a path that relaxes the size and/or content limits substantially, making it easier to deliver a general purpose payload.

Setting noexec on /tmp causes step 3 to fail. Well-behaved programs that need to do this should take instruction from the administrator about where to put their files.

[statikregimen]

Good insights...thanks. I will use the environment variable you mentioned instead. And I have to agree, knowing more, they (Mojang) should improve their practices on this.

[Hund]

Semi-OT: I would like to recommend the third party open source launcher called MultiMC[1]. It's created by some well known users from the modded Minecraft-community. It comes with a lot of features that the default launcher doesn't have, like having multiple instances of Minecraft in sandboxes, easy installation of Forge and Fabric et cetera.

1. https://multimc.org
_________________
Collect memories, not things.