Idea - Add Raspbian Support

[afyber]

Would it be possible to add support for Raspbian? When I try to run the generic 32-bit it says:

MultiMC Dir: /home/pi/MultiMC
No missing dependencies found.
./MultiMC: line 38: /home/pi/MultiMC/bin/MultiMC: cannot execute binary file: Exec format error

[peterix]

Well, that won't work. In this case, 'generic' means 'intel x86'.

Possible, sure. It's not impossible, but it would be a lot of work and it would require ongoing maintenance.

On the MultiMC side, it would involve some design changes and setting up a lot of build automation. Raspberry has an ARM CPU. I would need an ARM machine or at least some sort of emulation for running tests.

On the Minecraft end, the metadata would have to change to include native libraries for ARM, which I'd have to build, maintain and host somewhere. I can change the metadata, because MultiMC 0.6.0 no longer directly grabs that from Mojang anymore, so this is at the very least possible now.

I'd hoenstly rather do other things that benefit existing users. If you want this stuff for yourself, making an ARM build would be the first step. There are also some BSD patches that you could look at for integration with the system version of LWJGL -- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224823

Also, if you do any of this on your own, write the details down, push changes to github, tell me about it so it doesn't go away.

[DestyNova]

I'd like to help with this and have access to an RPi4. Is there an easy way to get started with this? It's been a long time since I wrote C++ code :grinning:

[DestyNova]

Ok! Got it to build using the following commands:

mkdir build && cd build
cmake -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang ..
make -j3

At first I had a problem with the Qt UI being waaaay bigger than my screen, perhaps to do with some sort of pixel scaling issue in my config. I fixed it by applying this environment variable:

QT_AUTO_SCREEN_SCALE_FACTOR=0

I've added this line to /etc/environment which I presume will sort the issue for a few other apps too (VLC and Xmoto both have been looking weird on this Pi for a while).

Then I tried to run MultiMC with 1.15.2 and, as expected, ran into a problem with lwjgl:

org.multimc.EntryPoint.main(EntryPoint.java:34)
Caused by: java.lang.RuntimeException: java.lang.UnsatisfiedLinkError: Failed to locate library: liblwjgl32.so
        at cxm.<clinit>(SourceFile:38)
        ... 11 more
Caused by: java.lang.UnsatisfiedLinkError: Failed to locate library: liblwjgl32.so

Will try to make more progress tomorrow.

[peterix]

Welp, keep me posted.

https://github.com/MultiMC/MultiMC5/issues/2133#issuecomment-363351735 is still completely valid, but if you can get this to the point where people can build and use it on their own, there's a chance.

[JJTech0130]

I have it built and provide a patcher for it... it only works when the pi is in ARM64 mode though... All you need to do is put the patcher as the pre-launch command. I also have up-to date arm64 builds. Check here for builds and here for the patcher.

[JJTech0130]

And no... you wouldn’t necessarily need an arm64 machine emulator for building it as you can just cross compile it (I’m currently trying to do that... haven’t finished it yet) and then relying on the community to test it.

[JJTech0130]

I don’t know if it had to do with the os your using, but I just changed it to use clang instead of g++ and it worked fine out of the box. It did need the patcher to make it actually run Minecraft, which required me to custom build LWJGL, but I currently use it daily without issues and was able to use it on several RPi4 64bit oses without issues. I found it runs the fastest on the 64bit gentoo with overclocking.

[comp500]

Since LWJGL 3.2.3, official ARM32/64 builds are available, and those work with the Pi 3 (I tested on 32bit raspbian but I'd assume the ARM64 builds also work on 64bit operating systems). Minecraft 1.13+ uses LWJGL 3.2.2 but it seems to be compatible with 3.2.3, so the official builds work.

For patching the LWJGL JSON, I made https://github.com/comp500/MultiMCPi a few weeks ago, but obviously that can be done in meta with the systems meta already uses.

In terms of compiling MultiMC itself, that's a bit more of a mess. I didn't manage to compile Qt (which most of the Qt cross compilation things use) but I managed to compile MultiMC on my Pi 3 using prebuilt Qt from Raspbian's repos. As @JJTech0130 said it does need clang to compile, but apart from that qmake works fine.

[DestyNova]

Yup, like I said it builds fine for me with clang. It just runs into the same lwjgl problem that's cropped up in all Minecraft versions since maybe 1.13. I'd like to make it build for vanilla 32-bit Raspbian, since I was able to run Minecraft 1.14 that way on an RPi4 by following these instructions. Presumably it's possible without Optifine too.

[comp500]

It is possible without Optifine - I've tested it with Fabric + Lithium + Sodium + Phosphor, although 1.13+ in general doesn't run very well on the Pi 3.

Another thing to note is that I ran into a segfault when closing the instance window, but it seems to save the changes properly.

Edit: I've put some rough build instructions in https://github.com/comp500/MultiMCPi if you want to run it on vanilla 32-bit Raspbian, that does install Java 14 but you can replace 14 with 8 if you want to use older Minecraft instances or Forge. (in theory it has better performance, but I haven't tested this) To actually run the game you'll want to make an instance with 1.13+, then select LWJGL 3 and click Customize on the right, then Edit. Run the script in my repo (or JJTech0130's) on the file that is opened, then you can start the game with the right native libraries. (might need a restart of MultiMC)

[JJTech0130]

You mention LWJGL problems, under 64bit os’es I have had no problems and can run pretty much any mods I’ve tried from 1.6 to 1.15... the versions that use LWJGL 1 don’t work but I have never seen anyone using them... the only thing is controller mods and the like that interact directly with the os don’t work but that’s a Linux problem it won’t run on my intel pc either

[JJTech0130]

I always use 64 bit oses for my pi’s anyway because it often performs better in some tasks especially sense most of the os’es are made exclusively for the pi4 and can use armv8 acceleration

[comp500]

I would have used a 64 bit OS, but I didn't manage to get Manjaro working with the proper GL driver - I think it's better supported on the pi 4. I think the aforementioned LWJGL problems were just because MultiMC was using the x86_64 binaries rather than the ARM32 ones, that's what the scripts fix.

[DestyNova]

@JJTech0130 agreed, I'd generally prefer to use a 64-bit OS myself, but my kid uses totally vanilla 32-bit Raspbian. It would be great to be able to say that (real) Minecraft is supported (almost) out-of-the-box on the Pi without needing to install a 64-bit OS :smiley:

Thanks @comp500 and @JJTech0130 -- this is really exciting already! Looking forward to trying your work on the weekend.

[JJTech0130]

I use this script to build it on my RPi Jenkins server FYI. I also use some other applications to publish artifacts to github automatically and to allow web hooks without bypassing the firewall (port forwarding) but they don’t really matter.

git submodule init
git submodule update
mkdir build
mkdir install
cd build
cmake -D MultiMC_META_URL:STRING="https://jjtech0130.github.io/meta-multimc/" CMAKE_CXX_COMPILER=clang++ CMAKE_C_COMPILER=clang CMAKE_INSTALL_PREFIX=../install ../
make -j3

[EDIT] I also use this script to package it into a .tar.gz release file like the official one as the normal packager fails when it realizes it is in a sandbox :smile:

cp ./application/package/linux/MultiMC ./install
mkdir ./install/bin
cp ./build/MultiMC ./install/bin/
cp ./build/libMultiMC_* ./install/bin/
cp ./build/jars/ ./install/bin/ -r
rm ./install/bin/jars/CMakeFiles/ -r
tar -zcvf build-$BUILD_NUMBER.tar.gz ./install

[EDIT] Added Meta URL parameter to cmake command

[JJTech0130]

Well... there is the 8GB Rpi4 now, and a beta 64 bit raspbian so that you can use all 8 gb in one process... that should make MC a lot ~faster~ :smile: EDIT: I see what you are saying, but it still help in both my cases - lots of mods, and a regular render distance (rather then running out of ram at anything higher then the lowest setting)

[dominic-03]

@JJTech0130 More RAM doesn't neccesarily mean it will run faster. Mine runs great with 2gb RAM allocated. Unless you use a lot of mods extra RAM can actually make it slower.

[comp500]

With the newer GCs (especially G1 and ZGC) allocating too much RAM isn't really a problem. The extra RAM will be useful for file caching though - you could even potentially use some of it as a ramdisk. However, 64 bit ARM has access to more registers, which means Java (especially newer versions like Java 14) should be faster than on 32 bit ARM. At some point though, you'll be limited by the graphics hardware anyway.

[JJTech0130]

Is this a bug? Exit code 0 should mean success, right?????

MultiMC version: 0.6.12-custom

Minecraft folder is:
/home/pi/MultiMC/instances/1.14/.minecraft

Java path is:
/usr/lib/jdk8u252-b09/bin/java

Java is version 1.8.0_252, using 32-bit architecture.

Running Pre-Launch command: ./patches/patcher.sh 1.14
The process failed to start.
Pre-Launch command failed with code 0.

And yes, this is 64-bit ARM java, it just doesn't detect it right. This only happens sometimes which is puzzling as there seems to be no logic to it failing or not. Sometimes it will run first try, sometimes requires a restart of MMC, sometimes a reboot, and, if all else fails, a re-install.

EDIT: Just for clarification, this was run on the 64-bit nspawn container in Raspberry Pi OS.

[JJTech0130]

On the 64 bit RPiOS it renders the QT window really large and then crashes the X server. It doesn't even get past the setup: the last thing it shows it the log it "Downloading Translations". Not sure why. I am not using 4k, only 1080p, so maybe it thinks it should render it in 4k? I have no idea. EDIT: Figured out a fix! You need to run export QT_AUTO_SCREEN_SCALE_FACTOR=0 before launching MultiMC. The only explanation I can think of it that it "auto-scales" to 4k. EDIT: :facepalm: Just realized this issue was already addressed ^^^^

[JJTech0130]

Here is a screenshot of it running the latest MC 1.15.2 without optifine on Hypixel on RPiOS 64bit:

There is still the "Exit Status 0" bug so you have to maually patch everything, but oh well The FPS are terrible without optifine, but thats just fine :smile:

[JJTech0130]

Found another bug: when you close the configuration window MultiMC crashes with a segfault: ./MultiMC: line 93: 30110 Segmentation fault "${MMC_DIR}/bin/MultiMC" -d "${MMC_DIR}" "$@" Should I file a bug? Or does it not count because it is an unsupported platform?

[JJTech0130]

Well. This is confusing. I found that if you use the ABSOLUTE PATH to the patcher and then run it ~2 times it will eventually succeed in running.

[JJTech0130]

But apparently my patcher's "Quick 'n Dirty" approach to patching LWJGL2 doesn't work on RPiOS 64-bit :cry: It says it cant find or run libawt_xawt.so. What is it? Google comes up with libawt.so, but not that! Here is the full error:

java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:196)
    at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:231)
    at org.multimc.EntryPoint.listen(EntryPoint.java:143)
    at org.multimc.EntryPoint.main(EntryPoint.java:34)
Caused by: java.lang.UnsatisfiedLinkError: /home/pi/MultiMC/instances/1.9/natives/liblwjgl.so: libawt_xawt.so: cannot open shared object file: No such file or directory (Possible cause: architecture word width mismatch)
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1850)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at org.lwjgl.Sys$1.run(Sys.java:72)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
    at org.lwjgl.Sys.loadLibrary(Sys.java:96)
    at org.lwjgl.Sys.<clinit>(Sys.java:117)
    at bcf.I(SourceFile:2744)
    at net.minecraft.client.main.Main.main(SourceFile:39)
Exiting with -1
    ... 8 more
Process exited with code 255.

[comp500]

Found another bug: when you close the configuration window MultiMC crashes with a segfault: ./MultiMC: line 93: 30110 Segmentation fault "${MMC_DIR}/bin/MultiMC" -d "${MMC_DIR}" "$@" Should I file a bug? Or does it not count because it is an unsupported platform?

I got that as well, not sure why. I'll probably run it with a debugger when I've got some free time.

It says it cant find or run libawt_xawt.so.

That's probably the AWT native library, not sure why it wouldn't work as it's bundled with your JVM. I think there were a couple tweaks that had to be made to get LWJGL 2 running on the Pi (there's a few threads on the Pi forums about this), but LWJGL 3 should work fine with the official downloads.

[JJTech0130]

Do you think its because I'm using Oracle Java? I will try again with OpenJDK later. Another thing could be that I need to recompile LWJGL 2 on the 64 bit RPiOS as I compiled it on Ubuntu last time. EDIT: Apparently it is an Oracle JVM thing. I installed OpenJDK 8 from their website and it fixed it immediately. Now I can run most every version of Minecraft.

[JJTech0130]

Here is a screenshot of Minecraft 1.9: It gets 25 FPS without optifine!

[JJTech0130]

I am compiling the jinput natives from their github repo using their Jenkinsfile and will test it once it finishes. Hopefully that will let me use the ~Controllable Mod~! EDIT: The mod mentioned above won't work at all, it has other issues with linux, but I am now trying with the Joypad Mod

EDIT: Hmm... it seems to ignore when I add custom jinput libraries to the org.lwjgl patch file, not sure why. Anyway, when I "hot-patch" it by swapping out the .so files as the program is running before it loads them, I get a new error: https://pastebin.com/ejV7gU1Q

BTW, there was another error before this that I am assuming is not relevent:

[18:26:47] [Client thread/ERROR] [Joypad Mod]: XInput: Controller object linking error. java.lang.UnsatisfiedLinkError: com.github.strikerx3.jxinput.natives.XInputNatives.getLoadedLibVersion()I

as google says that XInput is a win32 lib, and so maybe? this is just how the library checks what platform it is on.

[comp500]

LambdaControls should in theory work, as it uses GLFW's gamepad bindings, although it's only available for 1.15.2. I think JXInput (and whatever mod uses it) won't work as they are only available for Windows.

[JJTech0130]

Ok. I tried that and it detected the controller, however, it will not respond to button presses. I tried with bluetooth and USB. I see this error when I start mincraft but I'm not sure if it is related:

[19:18:50] [main/ERROR]: GLFW error collected during initialization: GLFW error during init: [0x10004]548327977288

Whenever I connect the controller I get this error:

[19:33:10] [main/ERROR]: ########## GL ERROR ##########
[19:33:10] [main/ERROR]: @ Render
[19:33:10] [main/ERROR]: 65540: Invalid button in gamepad mapping 050000005e040000fd02000003090000 (Xbox One Wireless Controller)

[comp500]

It might not have a mapping for the Xbox One Wireless Controller yet, I suggest you ask LambdAurora in the Fabric discord. It's probably best to not clog up this issue anyway, we've gone far off topic.

[JJTech0130]

OK. So I think in Build 34 it should get the meta files from Github Pages on my fork of the meta repo, so I can change the meta. But, on the first page it gets, there are SHA256 checksums under the name of everything. What are they generated from? The folder? Or the index file in that folder? I'll just try hashing things and see, and might also just try and omit them altogether for now.

EDIT: OK.... so it does not care at all if there are no hashes! So I can change out the libs on-the-fly! This is too easy... there must be a catch.

EDIT: I should probably try to recompile the old versions of LWJGL for maximum compatibility, but for now, it is OK!

EDIT: The first ARM64 release is here: https://github.com/JJTech0130/MultiMC5/releases/tag/0.6.11 No Patcher required!

[dominic-03]

Hey, @JJTech0130, could you try to cut down on your posts? I want to watch this issue but I'm getting nonstop emails. Maybe you could edit previous posts with more information?

[JJTech0130]

Just wanted to notify everyone:

1. I created a release that doesn't need a patcher and
2. I created a project to keep it organized here

EDIT: ARM32 release is on its way, unfortunately, it looks as if we will need 3 meta repos: 1 for x86 and x64, 1 for ARM64, and one for ARM32, until we get the architecture detection system to notice the diff. between them.

[JJTech0130]

OK.... ARM32 release is out. I only got it to work for versions <1.13, will work on that later. The main thing is, it is SLOW. Also OpenAL says it can't open /dev/dsp so it quits. On arm64, it took ~20 seconds for MC 1.8.9 to launch. On arm32, it took 5 minutes for it to load. Both of them had the assets and libs pre-downloaded. They were on the same machine.

[DestyNova]

That's pretty slow indeed :open_mouth:

Have you tried running with the aoss or padsp wrappers for /dev/dsp?

[JJTech0130]

On the 64 bit version, installing libopenal-dev fixed the issue and I can finally hear sound. I will try 32 bit in a moment. (As I said, it takes FOREVER to load :smile:) EDIT: The 64 bit version had another error not the /dev/dsp one... I think it did not need oss because the 64 bit version is using a newer version of LWJGL-OpenAL bindings, EDIT: The 32 bit version now works with ~oss-compat~osspd and libopenal-dev installed. I shall add them to the launch script dep. checker. EDIT: According to the man page of oss-compat you should now use osspd. I have not tried it but assume it should work the same

[JJTech0130]

Ok. So I build MMC in debug mode and ran it with gdb, and the segfault when closing the edit instance windows is generated by the function QWidgetPrivate::reparentFocusWidgets(QWidget*), which makes some sense because that should be where the parent window/widget is focused again. The thing that doesn’t make sense is why it generates a segfault. Is it a QT5 bug on ARM64? I posted the log and backtrace in this issue for anyone wanting to see the full thing. EDIT: Just found this issue: https://github.com/MultiMC/MultiMC5/issues/2797. So the only way to fix it is to use a different version of QT. EDIT: I just did a painful update to debian sid, and now there is no more QT bug! Also there is openjdk8 in sid so no more java errors! To bad it was so painful to install...

[dan9er]

In the meantime, has anyone tested MultiMC on Box86?

[dominic-03]

In the meantime, has anyone tested MultiMC on Box86?

I have not, though it would most likely result in much worse performance. I'm not sure if I'll have a chance to test it but I'll report back if I do.

[Kolpixx]

with Box86 it does not work for me.

[JJTech0130]

Do you think that MultiMC could work with the normal meta repo if this was enabled? That way you could run an “official” build with no modifications, and not have to worry about meta hosting. I will try it ASAP.

[kb-1000]

No.

[JJTech0130]

Ah. Ok. Why not? (I don’t actually understand what it does, but I thought maybe it would make it stop replacing custom libs)

[Painadath]

We have arm32 lwgl libraries and I run Minecraft java on my pi I just needs to use multimc

[Painadath]

And also we have both aarch64 and arm32 lwgl libraries

[TechDudie]

Why not???? seriously??? there are plenty of people with Microsoft accounts and raspberry pis

i cant wait until theres microsoft account support (or is there support already)a

not suppporting raspbian is NOT a good idea

this launcher is fantastic

[Painadath]

My firend uses multimc on his aarch64 pi IDK how he build it

[JJTech0130]

Everyone should use the version on pi-apps, it has Microsoft account support and is maintained by someone much more active than I am.

[Zetabite]

they should change the naming, to reflect the liscense