GZDoom 4.9.0 for ARM64 Windows (experimental)
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine are perfectly acceptable here too.
Please read the full rules for more details.
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine are perfectly acceptable here too.
Please read the full rules for more details.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
Randi should know, I think. I have no idea either how to set this up.
-
- Posts: 13797
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
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.mjr4077au wrote: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.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
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.
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.
-
- Site Admin
- Posts: 7749
- Joined: Wed Jul 09, 2003 10:30 pm
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
Yes, but I hacked in support for it to find that library with vcpkg if you're compiling for Windows._mental_ wrote:It appeared that FluidSynth uses pkg-config to find sndfile.
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.)Graf Zahl wrote:The CMake script is doing a lot of verification voodoo to see if the library is usable and this fails somehow.
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
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.
-
- Posts: 830
- Joined: Sun Jun 16, 2019 9:17 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Gosford NSW, Australia
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
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 etcRachael wrote: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.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
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.randi wrote:Yes, but I hacked in support for it to find that library with vcpkg if you're compiling for Windows._mental_ wrote:It appeared that FluidSynth uses pkg-config to find sndfile.
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.)Graf Zahl wrote:The CMake script is doing a lot of verification voodoo to see if the library is usable and this fails somehow.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
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.mjr4077au wrote: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
But knowing how those Linux types tick they will just ignore it and build against their globally,installed variants instead.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
I had to do this
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.
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
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
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.
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.
-
- Site Admin
- Posts: 7749
- Joined: Wed Jul 09, 2003 10:30 pm
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
? (A) is needed to use vcpkg with any CMake project, and (B) is just another configure option.Graf Zahl wrote:Wow, that's really complicated.
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.Graf Zahl wrote: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?
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.Graf Zahl wrote:I had to do this
It definitely works when building the DLL, so I don't know why the static library would be different.Graf Zahl wrote: But it still doesn't work right as it insists on linking against the shared CRT instead of the static one
glib is basically a system library on Linux.Graf Zahl wrote:Linux/macOS still needs work - it depends on whether we want to reference glib how much.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
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.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
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?
-
- Lead GZDoom+Raze Developer
- Posts: 49184
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
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.
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.
-
- Posts: 309
- Joined: Tue Apr 10, 2018 8:14 am
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
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)Rachael wrote: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.
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?
-
- Posts: 13797
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 4.8.0 for ARM64 Windows (experimental)
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
Just my thoughts, though, I might be the crazy one. lol