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.

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.

@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

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?

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.

Spoke to Pablo in private, and we've decided that Azahar will start using the Borked3DS fork of teakra

Thanks for the information