externals: Update all submodules to latest release/commit

[OpenSauce04]

Closes #579

The following are currently unable to be updated due to issues. These will be investigated and resolved before this PR is merged.

• fmt (breaks with >=11.1.3) This was actually OpenAL's fault
• openal-soft (breaks as of 1.24.2. Related: Fix compiling with libfmt>=11.0 dolphin-emu/dolphin#13262)
  • As this appears to be a general upstream issue, I have decided to upgrade to 1.24.1, the last working version, and stay there until the problem is resolved.
• glslang
• teakra (latest upstream is borked, probably need to switch to Borked3DS fork)
• vma
• vulkan-headers
• xbyak

[Ferdi265]

It's likely that what you are seeing is openal#1105, since openal links a vendored static copy of libfmt, which can cause issues if there are ABI incompatibilities between the versions used. This was fixed (by renaming the inline namespace in openal to fmt::v11_openal) on January 26th, but not released yet.

[rtiangha]

I figured out the vulkan-headers stuff a while back during the break; it requires changes to the emulator to work with the new 1.4 API (nothing major; just renaming a few things). Would you like me to submit a PR? Or you can just pull from this commit.

As for xbyak, it breaks the emulator at version 7.23 and greater because of strictly checking registers. I figured out a fix to make things work up to 7.23.1, but in 7.24, they added more checks and while the emulator technically will compile fine with that version, the standalone dynarmic executable won't (well, it does, but it fails during the tests phase) and I haven't had the time to really delve into that. It might be okay since the emulator only compiles against dynarmic's library files, but if 7.24 is actually exposing some flaws that don't appear until it's compiled against its frontend, then it might not be worth upgrading to that until things are fixed (and since there's no one upstream maintaining it anymore, it'd need to be fixed by someone on this end). Else, 7.22 (or technically, commit 7123dd6) is the last version to work without modifications to the emulator.

As for fmt, I found that while 11.1.3 will compile fine, it breaks downloading system files. The list of commits between versions isn't that big; my guess is that things need to be changed on this end to work with changes to format.h (or it could be something else; haven't had time to look into it too much).

As for the other dependencies, I can't recall encountering issues in upgrading them. Maybe glslang a while back, but I can't remember what the issue was.

[OpenSauce04]

@rtiangha Thanks for bringing this up, I will pull your fixes into this pr myself.

I also discovered that updating teakra is causing test failures on Linux and MacOS in CI, which I missed last night because I didn't experience the issue locally. Do you know anything of this?

Here's a CI run showing the issue: https://github.com/OpenSauce04/azahar/actions/runs/13632714607/job/38103946956

[OpenSauce04]

It seems like in Borked3DS you had to switch to a fork of teakra.
@PabloMK7 Should we also switch to this forked version of teakra?

[rtiangha]

That version of Teakra is based off of GPUCode's x86 accelerated version of Teakra. I switched to it because it looked interesting and thought it might offer better performance, although I don't really know how to test for that. It kept working though, so I stuck with it. I do know that the Mikage project was thinking of switching to it too, with modifications to work with the audio timing changes they were making to their emulator. The arm versions still use Teakra Classic, so I actually use both and use cmake to determine which one to use.

The thing is, that Teakra's HEAD doesn't actually compile anymore. GPUCode introduced this commit which isn't actually complete. It's missing a header file and the correct constructor (I think this person may have fixed it). From what I can tell, it was also meant to pair with some changes on the emulator end, of which a PR was actually submitted against PabloMK7's fork, but it didn't fully compile and no work was put in to finish it. But it was also part of the change to nuke savestate support until a better alternative could be found, but that was never completed either. I don't know if the memory changes will work without PR 42 though.

Anyway, my long winded way of saying that to make that version of Teakra work, I had to fork off from commit beae4c37.

That said, the MacOS one is happening because upgrading zstd activates certain tests by default, and it fails because it can't find some of the testing executables. I don't know why that happens since zstd is set to compile them anyway. It's probably a path thing and maybe easily fixable (either by tweaking the cmake script or installing the equivalent OS system packages), but I never put the time in and went the easier route of just disabling it since it made it no different from the previous behaviour (Edit: Oops, I wasn't entirely correct; Teakra needed some modifications too, which you can automatically pull in if you update the project's Teakra version to HEAD). It would be nice to fix things properly, though.

The Linux errors are new to me, probably because of the switch. I could take a stab at trying to fix things, though; looks like it could be fixed on the emulator end which makes things easier. Let me know if you'd like me to try.

[OpenSauce04]

Spoke to Pablo in private, and we've decided that Azahar will start using the Borked3DS fork of teakra. The upstream repository looks very dead from the commit dates.

Thanks for the information

[OpenSauce04]

@rtiangha I seem to be unable to compile for ARM platforms using the forked version of teakra due to the following new error:

fatal error: no member named 'Reg64' in namespace 'Xbyak'

In your message you briefly mentioned you were using an older version of teakra for ARM devices but didn't elaborate on it much.

Is this something we must do as well if we wish to use the forked library? If so, is there any particular reason why the fork can't support both architectures? Having two copies of the same library in the same project seems suboptimal.

[rtiangha]

Yeah, GPUCode's Teakra won't compile on arm, so I actually have two Teakra submodules in my externals:

• teakra (which is GPUCode's teakra)
• teakra-old (which is the original teakra before GPUCode's modifications, although it's a dumb name, lol; use teakra-classic instead please).

I have teakra-classic set up as a separate branch called teakra-old to keep it all in one repository.

To make the switch, basically clone teakra a second time (assuming root directory):

git submodule add https://github.com/Borked3DS/teakra.git externals/teakra-classic
cd externals/teakra-classic
git checkout teakra-old

Then edit .gitmodules to make it explicit that it's a branch:

[submodule "teakra-classic"]
    path = externals/teakra-classic
    url = https://github.com/Borked3DS/teakra
    branch = teakra-old

And then modify externals/CMakeLists.txt with something similar to this, although make it look like this:

if ("x86_64" IN_LIST ARCHITECTURE)
    add_subdirectory(teakra EXCLUDE_FROM_ALL)
else() # use older teakra for arm builds for now
    add_subdirectory(teakra-classic teakra EXCLUDE_FROM_ALL)
endif()

And of course,

git add .gitmodules externals/teakra-classic externals/CMakeList.txt
git commit

Maybe there's an easier way to do things; didn't really think about it too hard.

[OpenSauce04]

Hm. Ok then, I'll just merge the other submodules in for now and then come back to teakra later. I want to see if I can get the fork to work with ARM, which may be a bit out of my depth, but you never know until you try. If that doesn't end up working, I'll re-evaluate the situation.

Thanks for your help with this PR 🙂

[rtiangha]

It might be possible; the fork just assumes that you're on x86 so I think there'd just need to be checks for the arm path to use the older code. Of course, that assumes that the older code that works on arm wasn't over written in the first place. I never looked into it closely.

Edit: Of course, it'd be cool to port the x86 XByak code to use Xbyak_aarch64 equivalents for the arm path, but that's pie-in-the-sky.