Closed bbbradsmith closed 7 months ago
After looking into this, I've decided I should not proceed at this point. I think it is possible for the Libretro organization to build Wii and Wii U cores with their build system, but I don't think I have access to what I need independently.
container: devkitpro/devkitppc:latest
on the build step in Github Actions, which gives me a container with devkitPro already set up. This does allow installation of the tools, but I'm not sure if they're exactly what is needed.On the CI machine, using this build Script: build.yml
It got as far as linking, and then failed with many errors that look like it's trying to bind with a core that it hasn't been given. I couldn't find instructions about how to resolve this. As far as I know the makefile with no parameters should build the main application, not try to build a bound static core?
LD objs/wiiu/retroarch_wiiu.rpx.elf
/opt/devkitpro/devkitPPC/bin/../lib/gcc/powerpc-eabi/13.2.0/../../../../powerpc-eabi/bin/ld: objs/wiiu/runloop.o: in function `libretro_get_system_info':
runloop.c:(.text.libretro_get_system_info+0x80): undefined reference to `retro_set_environment'
On my local machine, it complained about not being able to find zlib. I tried HAVE_ZLIB=0
and then it complained about rzipstream_read_file
, and I decided not to keep chasing this rabbit.
This is unknown, I didn't get as far as trying. The SDL2 dependency may be a problem, but maybe Libretro has a special Wii U SDL2 that could be used.
If SDL2 can't be built, we might be able to reproduce the very small subset of SDL2 that is needed. I explained how to do this in DEVELOP.md but it just hasn't been worth the effort yet.
Otherwise I think the rest should be doable. Hatari and hatariB seem to run fine on various Arm architectures so far. As long as we can build the core into a library, we should be able to statically bind the core to a build of RetroArch. We need to be able to build RetroArch first, though.
Because the Wii and Wii U RetroArch cores are actually a static combination of the core and the entire RetroArch application, we can't mix-and-match cores manually the way it works on other systems where they're a separate shared object of some form. It seems dangerous to just pick one version and hope users are able to use it.
I've got to put a pin in this, personally. It doesn't seem worth the effort at this point. If I could manage to build it locally I'd consider continuing, but where I got to I don't know if I'm 1 build test cycle away from getting there, or 100. The Actions runner seemed to get farther, but every build cycle is much slower when you don't have your hands on the machine.
I believe eventually if it becomes a Libretro core, we can support the Wii and Wii U through their official build system. The same goes for a number of other platforms, which I don't have suitable hardware to test with at this point.
However, if a contributor can resolve how to get the Github Actions CI build working here for this platform (or any other reasonable platform), please submit a PR and I'll add it. This build.yml from my test PR might get you started.
I might be able to test this out with my Wii U since Tiramisu makes it easy to access. Should be able to try the virtual Wii homebrew too.
The libretro/hatari CI build should probably help understand how to compile: https://git.libretro.com/libretro/hatari/-/pipelines
The compiler toolchain is called DevKitPro: https://devkitpro.org/wiki/Getting_Started
Some of it seems like it should be similar in nature to the RPi builds, but it generates a static ELF instead of an SO. Because it's not a shared object, RetroArch actually switches total execution to the core, so building for these platforms involves including that subset of RetroArch needed to support the static core. Info: