GZDoom 4.9.0 for ARM64 Windows (experimental)

[Graf Zahl]

Randi should know, I think. I have no idea either how to set this up.

[Rachael]

While the Raze package I maintain in Arch Linux's AUR maintains the repository-included libraries, some distros are going to the effort to unbundle these so system libraries are used.

Could we have it so distro-provided builds of GZDoom and Raze are supported, just so long as they're built to our specification, with our tested and mandated libraries? I don't know of any distros that will repackage someone else's binaries, especially when there is source availalble.

Distros can do what they want - the source is there. But when people using these distros start having problems - particularly with the libraries - then we may have to recommend they use our binaries instead.

I don't see any reason to block distros from doing things the way they want to do them. I was just expressing my opinion that I think it would be hugely beneficial that if we're going to have mega-static executables for Windows, we should do it for all platforms, it greatly simplifies distribution.

For Mac having MoltenVK separate is not a huge deal since it's ultimately part of the App bundle anyway and no one really grabs files out of that unless they need to open the .pk3's in Slade or any other map editor. I think it might still be advantages to having it linked statically though.

While we're on that note, I think it's a bit of a misleading to label it "Vulkan" on Mac since all it does is tie to the Metal backend anyhow. Yes - the coding and functions are the same since we use a wrapper, but ultimately the API commands being emitted by the application will end up being Metal.

[Graf Zahl]

For Mac it doesn't really matter if the app bundle contains a single executable or several dylibs. The bundle is a static inseparable package that's being signed as a unit.

For Linux we have to make clear, though, that alternative compiles other people create and deviate from our own setup come without any tech support. Not that I'd ever expect things to change here.

[randi]

It appeared that FluidSynth uses pkg-config to find sndfile.

Yes, but I hacked in support for it to find that library with vcpkg if you're compiling for Windows.

The CMake script is doing a lot of verification voodoo to see if the library is usable and this fails somehow.

a) Is the CMake toolchain file set for vcpkg? If you opened it as a Folder Project in VS 2022, VS will do that for you. Otherwise, you need to specify it on the command-line -DCMAKE_TOOLCHAIN_FILE=[path to vcpkg]/scripts/buildsystems/vcpkg.cmake (I think you only need that the first time you generate.)
b) VCPKG_TARGET_TRIPLET needs to be set to your desired triplet so it doesn't default to <arch>-windows. Since you want everything to be static, you can use the triplet x64-windows-static and not need to mess around with a custom triplet at all.

I also had to delete the cache and reconfigure to keep it from trying to use the DLL version of libsndfile I last linked against, but it worked for me:

Code: Select all

    Directory: D:\src\fluidsynth\out\build\x64-Release\src

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           7/30/2022  5:21 PM        1652958 libfluidsynth.lib

Well, maybe "worked" is a little too strong a word, because it also compiled libsndfile into it instead of leaving it external.

Edit: Nevermind. I forgot it would be larger than the corresponding DLL because the static library has all that extra metadata that the DLL doesn't. It looks like it doesn't actually have libsndfile compiled in.

[mjr4077au]

Distros can do what they want - the source is there. But when people using these distros start having problems - particularly with the libraries - then we may have to recommend they use our binaries instead.

I don't see any reason to block distros from doing things the way they want to do them. I was just expressing my opinion that I think it would be hugely beneficial that if we're going to have mega-static executables for Windows, we should do it for all platforms, it greatly simplifies distribution.

All I meant here is that a binary built by a distro that's built the way we would build the binary should be equally supported. If they want to go off track like openSUSE has, then they're free to do so without support if they have esoteric bugs etc

[Graf Zahl]

It appeared that FluidSynth uses pkg-config to find sndfile.

Yes, but I hacked in support for it to find that library with vcpkg if you're compiling for Windows.

The CMake script is doing a lot of verification voodoo to see if the library is usable and this fails somehow.

a) Is the CMake toolchain file set for vcpkg? If you opened it as a Folder Project in VS 2022, VS will do that for you. Otherwise, you need to specify it on the command-line -DCMAKE_TOOLCHAIN_FILE=[path to vcpkg]/scripts/buildsystems/vcpkg.cmake (I think you only need that the first time you generate.)
b) VCPKG_TARGET_TRIPLET needs to be set to your desired triplet so it doesn't default to <arch>-windows. Since you want everything to be static, you can use the triplet x64-windows-static and not need to mess around with a custom triplet at all.

Wow, that's really complicated. I guess it would all be a lot easier if it didn't have that stupid glib dependency by default. Have you tried to PR your changes to upstream? If it was there by default, I guess things would be easier as we could use vcpkg's compiled .lib file directly.

[Graf Zahl]

All I meant here is that a binary built by a distro that's built the way we would build the binary should be equally supported. If they want to go off track like openSUSE has, then they're free to do so without support if they have esoteric bugs etc

It's not really that easy. Even if it is all built the same way, some of these libraries are so highly configurable that nothing can be taken for granted and making an error when setting it all up is very easy. We'd have to provide the files ourselves as a binary package.
But knowing how those Linux types tick they will just ignore it and build against their globally,installed variants instead.

[Graf Zahl]

I had to do this

Code: Select all

#if LIBSNDFILE_SUPPORT
#include <sndfile.h>
#elif __has_include("sndfile.h")
#undef LIBSNDFILE_SUPPORT
#define LIBSNDFILE_SUPPORT 1
#include "sndfile.h"
#pragma message("sndfile support active.")
#endif

to persuade FluidSynth to compile with sndfile support. But it still doesn't work right as it insists on linking against the shared CRT instead of the static one - the option in the project simply seems to be ignored.
At this point I think the only option to get this into a state where we can handle this mess is to directly include the needed parts into ZMusic - that'd also help with the compatibility issues in the past with API/ABI breaks between versions. We do not need the latest and greatest here, but something that *just* works.

I also had a quick look at libinstpatch, but that seems to be a lost cause, it seems to utterly depend on glib - although DLS support on Windows would have been nice.

[Graf Zahl]

Mostly done. On Windows it compiles and works now with FluidSynth being inside the ZMusic source tree.
Linux/macOS still needs work - it depends on whether we want to reference glib how much.

In case glib is fine, the library detection needs to be updated, but if we don't and instead use a wrapper similar to Windows, the glibstubs file needs to be redone here.

[randi]

Wow, that's really complicated.

? (A) is needed to use vcpkg with any CMake project, and (B) is just another configure option.

I guess it would all be a lot easier if it didn't have that stupid glib dependency by default. Have you tried to PR your changes to upstream?

Removing the glib dependency for Windows has been proposed several times over the years, and it always gets shot down. They're not interested unless it's something that can replace glib on all the platforms they currently support. And now they're using glib for LADSPA as well as threading, so that complicates matters further. I consider a PR a lost cause. The most recent attempt by someone was just last year.

I had to do this

Just to be sure, did you delete all your generated CMake files to be sure nothing was held over from your previous attempts? I have no trouble getting it to find whatever vcpkg-built triplet version I want as long as I start fresh when changing the triplet.

But it still doesn't work right as it insists on linking against the shared CRT instead of the static one

It definitely works when building the DLL, so I don't know why the static library would be different.

Linux/macOS still needs work - it depends on whether we want to reference glib how much.

glib is basically a system library on Linux.

[Graf Zahl]

The problem with that vcpkg toolchain file is that it can only be done via command line, so it configures everything outside the GUI and I end up with even more work - so I avoid doing stuff like that.

I had an hour-long fight against the project - even including it in ZMusic required a lot of editing of the messy project. But since we cannot use the original repo available in vcpkg due to the glib mess I'd rather do it in a way that eliminates the mess once and for all. FluidSynth has already broken both ABI and API in the past and the general attitude seems to make it likely to happen again, so we're better off with our own copy inside ZMusic - with this we can even make the needed changes to support embedded sound fonts in the future. Win-win.

[Graf Zahl]

Hm, I need some help with glib. When trying find_package( glib ) on my MacBook CMake throws an error, claiming not to know it. So how do I set that up?

[Graf Zahl]

Got it sorted out. Parts of the FluidSynth CMake project did not mix with how ZMusic had set up things, and stuff had different names for some reason.

One big oroblem less, I'd say, now that we have this code under our own control. Gotta make some token changes to keep the Linux maintainers from reverting to the system-installed versions, though.

[Phredreeke]

While we're on that note, I think it's a bit of a misleading to label it "Vulkan" on Mac since all it does is tie to the Metal backend anyhow. Yes - the coding and functions are the same since we use a wrapper, but ultimately the API commands being emitted by the application will end up being Metal.

Are you suggesting renaming the Vulkan backend on Mac builds? (though with the other backends going away in 5.0 maybe there's no point in making the distinction anyway)

Anyway, since this topic is about GZDoom on ARM64 Windows, I'm gonna ask about something that has been on my mind for a while now, how is the GPU support on this platform?

[Rachael]

Yeah we should probably either just call it Metal, or just call it by the wrapper name MoltenVK. Since Vulkan does not actually exist on the MacOS platform.

Just my thoughts, though, I might be the crazy one. lol