Closed carlo-bramini closed 8 months ago
The reason I did not pull this in initially is because it seemed to break my VS 2019 setup, although I forget the details now. And of course I have no way to test a Windows ARM64 build (still not even really sure what that is). But I'm happy to bring something in if it doesn't break my setup and others claim it works. Sorry @carlo-bramini I didn't post before... :(
As for making multithreading the default @ArminiusTux, yes it would certainly make sense in a future release, if not the next. I just thought I'd give it a little bake time to make sure it didn't break in some situations, but so far it's been really stable.
Hello and sorry for the late reply.
I managed to update all the *.vcxproj files, which leads to a successful ARM64 compilation.
However the result is unuseable as all EXEs hang (Debug & Release).
It turned out that the wavpackdll.dll
is faulty, cause if replaced (by a cmake+msvc shared dll build) the executables are fine.
Any suggestions?
Hello!
after lot of time, I tried to build again wavpack for WOA and actually you are right, it seems that /DINAMICBASE
isn't supported on ARM devices.
See:
https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase?view=msvc-170
I'm sorry, I don't understand how I could not seen it in the past, but hopefully this can be easily fixed into the settings of the project and, if I understood correctly, you already did when doing your successful ARM64 compilation.
No problem. But if I understand @ArminiusTux correctly, he was able to fix the compilation, but the DLL does not work (hangs).
@carlo-bramini were you actually able to get this to run on an ARM64 machine back when you originally created the patch? If not then including this might be premature. Unfortunately I have no such hardware or expertise.
Good evening to you both,
indeed compilation works but libwavpack (the shared wavpackdll.dll) is most likely causing the hang.
I also took the clean v5.7.0 source (without the ARM additions) and got this upon cloning the configuration profile (x64->ARM64):
Maybe those assembler optimizations (for x86 & x64 only) are somehow being applied to the ARM64 build despite being defined for exclusion in the libwavpack.vcxproj
. Is there a neat way to drop them altogether (just for testing)?
Unfortunately I have no such hardware or expertise.
Well @dbry the need for real metal or silicon, is no longer a must. 😉
Happy Easter!
Happy Easter!
I too thought about it being the ASM code, but I looked in your build dump and they're not listed, and there's no ASM involved in the WavpackGetLibraryVersionString()
function which seems to be hanging in your example. My guess is that it's an ABI issue, although I would normally assume that would crash rather than hang. Kind of a mystery.
If I had a spare week I would dig into it, but I'm short on time and, to tell the truth, interest (especially when there are other ways to build this). Unless someone comes to the rescue I might pull this out before anyone gets hurt. :smiley:
By all means @dbry , let's rewind this cassette 📼 and remove the ARM64 VisualStudio additions for the time being.
Perhaps, it is also true that all files for VisualStudio may be simply deleted.
Unless there are particular reasons for keeping them, the IDE should be perfectly able to open the CMakeLists.txt
file and re-create the solution and the project files for the platform you want, i686, x64 and ARM64, making shared or static libraries and so on.
EDIT: this way just needs to update the README file with the build instructions for Windows when using MSVC, actually.
MinGW, MSYS2 and CYGWIN can just follow the same behaviour of unix-like systems.
Okay, for now I've pulled out the ARM64 mods. We can look into this later, but for now Cmake+MSVC
will do the job, or I use Cmake+mingw
on Linux to build everything, even the Cool Edit and Winamp plugins (although those of course do not have ARM64 equivalents).
Thanks both of you!
A great addition @carlo-bramini , however I failed in compiling your v5.4.0 ARM tree.
wavpack.sln was used with VS 2022 (version 17.9.2):
Would you mind updating your changes against the new v5.7.0 source, please?
As for compiling WavPack for Windows on ARM in general ...
... it works with Cmake+MSVC & also MSYS2 (Cmake/Clang/Ninja).The multithreading gains are fantastic, thanks @dbry for this addition!
Please consider turning this welcome feature ON by default in a future version (v6?).