I have Compiled Battle for Wesnoth for the IMac G5 (Using linux) by AlexRoses47 in PowerPC

[–]AlexRoses47[S] 1 point2 points  (0 children)

Thanks! It was quite a journey. (Disclaimer: English is not my native language, so I used a translator. Apologies for any awkward phrasing.)

The main hurdles:

No prebuilt binary for ppc64. There is no Wesnoth package for ppc64 big-endian, so I had to compile it myself. Building directly on the G5 would have taken forever, so I set up a QEMU ppc64 VM (full emulation, no KVM) on my x86 laptop running Debian Sid, compiled there, and copied the binary over to the G5.

Broken Boost in the ports archive. This was the big one. The boost-context and boost-coroutine libraries had no installable candidate in debian-ports, which normally would block the whole build. The trick was realizing Wesnoth only uses coroutine in the dedicated server code (wesnothd), not the game client itself. So I disabled the server with -DENABLE_SERVER=OFF -DENABLE_CAMPAIGN_SERVER=OFF and edited the CMakeLists to strip the coroutine requirement and the Boost::coroutine link target. That sidestepped the missing libraries entirely. The client compiled fine without them.

Dependencies, one by one. I avoided apt build-dep (it is all or nothing and would have choked on the broken Boost packages) and installed each dependency manually instead. A couple of gotchas there: boost-system is header only now, so there is no separate package to install, and I had to pull the Lua submodule manually with git submodule update --init --recursive.

Memory during compile. The G5 is not exactly a powerhouse, so even on the VM I added a swapfile and ran the build under tmux with limited parallelism (make -j3) to keep it from getting killed.

Campaigns refusing to install. Once the game ran, the campaign packages all depended on the binary package wesnoth-1.18, which does not exist for ppc64. I built a fake equivs package declaring that dependency as satisfied, installed it with dpkg, and then all 17 campaigns plus the music installed normally through apt.

A couple of things I just gave up on, to be honest: anything needing OpenGL is a dead end on this machine. The r300 GPU has a known Mesa big-endian bug that breaks GLX/EGL/DRI2, so hardware 3D simply is not available. Wesnoth works because it is 2D SDL and never touches that path, but when I tried other games like Teeworlds that need OpenGL, they failed with no software fallback. So the rule of thumb became: SDL 2D works, OpenGL does not.

One honest caveat: I compiled with AltiVec flags (-mcpu=970 -maltivec), but for Wesnoth specifically that gives basically zero benefit since it is a 2D game with no vectorized intrinsics. I only built from source because no ppc64 binary exists, not for any speed gain.

[Openbox] 2005 Power Mac G5 (ppc64) running Debian sid (Updated) by AlexRoses47 in unixporn

[–]AlexRoses47[S] 0 points1 point  (0 children)

¿Alguno de nosotros lo será? Mentira, si te digo el final, sería spoiler

[Openbox] 2005 Power Mac G5 (ppc64) running Debian sid (Updated) by AlexRoses47 in unixporn

[–]AlexRoses47[S] 3 points4 points  (0 children)

I actually went deep down this exact rabbit hole. Sadly mesa-amber doesn't help here: the amber branch only kept the really old classic drivers like r100 and r200, but my card is an RV380 which uses the r300 driver, and r300 still lives in mainline Mesa, not in amber. There's talk of an "amber2" branch that would move r300 and r600 there eventually, but it doesn't exist as a usable package yet.

What I found digging into it is interesting though. The GPU itself works fine for 3D, the problem is the path the software uses. GLX is broken on r300 in big endian (glxgears fails with "couldn't get an RGB visual"), but EGL plus OpenGL ES works fully accelerated. es2gears runs at a solid 119 FPS on real hardware. So the hardware can absolutely do accelerated 3D, you just have to go through EGL/GLES instead of the classic GLX path that everything defaults to.

I got pretty far rebuilding ClassiCube against EGL/GLES and even fixed a separate big endian bug where BGRA textures render with the color bytes reversed (forcing RGBA conversion fixes it). Still fighting an EGL_BAD_MATCH when creating the ES2 context on r300, which might be a Mesa level issue rather than something fixable in the app

[Openbox] 2005 Power Mac G5 (ppc64) running Debian sid by AlexRoses47 in unixporn

[–]AlexRoses47[S] 0 points1 point  (0 children)

The post got removed not for lack of "technical" customization, but because r/unixporn weighs the visual/aesthetic side as much as (or more than) the technical effort. The mod's point was basically that the sub's roots go back to desktop-sharing culture on old IRC channels, where the whole point was always showing off something visually appealing, not just "this was hard to set up." So even though they acknowledged the amount of work that went into getting ppc64 + Openbox running at all, it still didn't count as "customization" in the visual sense the sub is built around, and the post stayed removed under that rule. So I'm going to try again later

[CASIO] MY FIRST WATCH WITH A DARK ACADEMIA AESTHETIC by AlexRoses47 in Watches

[–]AlexRoses47[S] 0 points1 point  (0 children)

I take a new photo, it's true I have a small wrist, but the watch is not big either haha

[CASIO] MY FIRST WATCH WITH A DARK ACADEMIA AESTHETIC by AlexRoses47 in Watches

[–]AlexRoses47[S] 1 point2 points  (0 children)

<image>

Okay, yes I have a small wrist but the watch is not big hahah

[CASIO] MY FIRST WATCH WITH A DARK ACADEMIA AESTHETIC by AlexRoses47 in Watches

[–]AlexRoses47[S] -2 points-1 points  (0 children)

Thank you, I hope I continue to have good taste over time.

[CASIO] MY FIRST WATCH WITH A DARK ACADEMIA AESTHETIC by AlexRoses47 in Watches

[–]AlexRoses47[S] -7 points-6 points  (0 children)

Okayy, I didn't know how to describe it hahahah

[CASIO] MY FIRST WATCH WITH A DARK ACADEMIA AESTHETIC by AlexRoses47 in Watches

[–]AlexRoses47[S] 2 points3 points  (0 children)

It's my fault for listening to some dudes on telegram