I removed it because the 32-bit version doesn't support the latest version anymore. This is due to the fact that an external mod is now required to get the launcher to work with the newer versions due to DRM.

Hi, is there a reason for the removal of the lib32 build? I don't see support having been dropped upstream.

PS: Don't see this as a request to add it back, I'm just curious about whatever has changed.

Some try and errors later. Something is wired. After leaving the app I can only login after. rm -rf .cache/Minecraft\ Linux\ Launcher .config/Minecraft\ Linux\ Launcher .config/QtProject* && mkdir .config/QtProject and doing the full re-login again.

And inside Minecraft I am not able to login to my M$ Account. Just an infinite window waiting for whatever.

Perhaps worth to mention here. I got a lot of "Speicherabzugsfehler" when trying to run. No chance to run Minecraft again.

After some digging I got it working again by creating a missing (empty) Directory: mkdir -p ${HOME}/.config/QtProject

After this I could start mcpe again (and play the game).

I've tried building and running in two different systems and I get the same buffer overflow error:

19:44:06 Info  [Launcher] Version: client 89d4f5c / manifest cfb5ca5
19:44:06 Info  [Launcher] OS: Linux
19:44:06 Info  [Launcher] Arch: x86_64
19:44:06 Info  [Launcher] CPU: AuthenticAMD AMD Ryzen 5 5600X 6-Core Processor             
19:44:06 Info  [Launcher] CPU supports SSSE3: YES
19:44:06 Info  [Launcher] Reading Launcher Settings File: /home/dimitris/.local/share/mcpelauncher/mcpelauncher-client-settings.txt
19:44:06 Info  [Launcher] Applied Launcher Settings
19:44:06 Trace [Launcher] Loading android libraries
19:44:06 Trace [Launcher] linker loaded
19:44:06 Trace [REDIRECT] /data/data/com.mojang.minecraftpe to /home/dimitris/.local/share/mcpelauncher/
19:44:06 Trace [REDIRECT] /data/data/usr/proc/52722/cmdline to /home/dimitris/.local/share/mcpelauncher/
19:44:06 Trace [REDIRECT] /data/data/mcpelauncher-client to /home/dimitris/.local/share/mcpelauncher/
19:44:06 Trace [REDIRECT] /data/data to /home/dimitris/.local/share/mcpelauncher/
19:44:06 Trace [REDIRECT] . to /home/dimitris/.local/share/mcpelauncher/versions/1.21.92.1/assets/
19:44:06 Trace [LinkerUtils] Loaded OS library libm.so.6
19:44:06 Trace [LinkerUtils] Loaded OS library libz.so.1
*** buffer overflow detected ***: terminated
Signal 6 received
Backtrace elements: 17
# 0 mcpelauncher-client(+0x40bea9) [0x557440fdaea9]
# 1 /usr/lib/libc.so.6(+0x3def0) [0x7f29d1a4def0]
# 2 /usr/lib/libc.so.6(+0x9774c) [0x7f29d1aa774c]
# 3 /usr/lib/libc.so.6(gsignal+0x20) [0x7f29d1a4ddc0]
# 4 /usr/lib/libc.so.6(abort+0x26) [0x7f29d1a3557a]
# 5 /usr/lib/libc.so.6(+0x265c9) [0x7f29d1a365c9]
# 6 /usr/lib/libc.so.6(+0x124a09) [0x7f29d1b34a09]
# 7 /usr/lib/libc.so.6(+0x124374) [0x7f29d1b34374]
# 8 /usr/lib/libc.so.6(+0x125b1b) [0x7f29d1b35b1b]
# 9 mcpelauncher-client(+0x4cfeaf) [0x55744109eeaf]
# 10 mcpelauncher-client(+0x4cfd3f) [0x55744109ed3f]
# 11 mcpelauncher-client(+0x4c8578) [0x557441097578]
# 12 mcpelauncher-client(+0x4c6bc7) [0x557441095bc7]
# 13 mcpelauncher-client(+0x1719e7) [0x557440d409e7]
# 14 /usr/lib/libc.so.6(+0x276b5) [0x7f29d1a376b5]
# 15 /usr/lib/libc.so.6(__libc_start_main+0x89) [0x7f29d1a37769]
# 16 mcpelauncher-client(+0x16bb25) [0x557440d3ab25]
Dumping stack...
program failed with unix signal number: 6

any ideas?

@HurricanePootis Thank you kindly for the swift response and explanation! Problem has been resolved :)

@Atronin, that is an issue with how paru handles packages that use a git source. To your /etc/paru.conf, to IgnoreDevel and IgnoreDevelSource, add my package. This is because paru thinks that a PKGBUILD using a git repo as the primary source is a -git package, it uses the rebuild function. However, this is not true.

There's an issue with this package that causes the AUR helper paru to constantly ping it as outdated, saying that the new version is "latest-commit" (instead of the usual numerical format), proceeding with a pointless reinstall that helps the notification go away until the next reboot. Then the process repeats - and of course, the package always stays at 1.3.0-2.

This issue does not appear with the AUR helper yay, but can be replicated across different devices. It's the only one across over 30 AUR packages I use to have this problem.

Can anything be done to resolve it?

Nice catch, @gwuensch. Looks like the PKGBUILD should be modified as:

        CFLAGS+=" -flto=thin"
        LDFLAGS+=" -fuse-ld=lld"

or, alternatively:

        CFLAGS="$CFLAGS -flto=thin"
        LDFLAGS="$LDFLAGS -fuse-ld=lld"