wimlib

I'll add fallback definitions for those RENAME_* constants.

For the error in sha1.c, would you mind just using gcc 4.9 or later? It's already a decade old.

It comes from "SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName" in the Windows registry. So it must still say Windows 10. If there's something else that should be used instead, wimlib could look at that.

Thanks, I've fixed the date.

I've released wimlib 1.14.4: Fixed potential crash when writing WIM XML data, introduced in v1.14.0. Improved some documentation. Fixed the Windows build script to avoid an unnecessary DLL dependency when building with MSYS2 MINGW32 or MSYS2 MINGW64. The files and their SHA-256 checksums are: 3633db...

Since this is off-topic from ARM64 support, can you please create a new thread? Please include a clear report of the issue, including the error message(s) you're currently seeing and attaching the DLL that's not working. Please use the latest git master branch only, without anything reverted , and i...

That's also the old code, not the new code, so make sure you've run 'git pull'...

Yes, I haven't seen the issue on newer operating systems such as Windows 10, and surely wouldn't run into it on Windows Server 2022 either.

Why not do the build on one of those, then?

(I would also encourage you to start a new thread if you have issues that are unrelated to the ARM64 support, which this thread is about.)

Hi, It turned out that the windows-build.sh script had a bug that made it not use the -static-libgcc compiler flag in the MINGW32 and MINGW64 MSYS2 environments as intended, causing the DLL to depend on libgcc. I've pushed out a commit that fixed this. This did not affect the official i686 and x86_6...

What dependency problems are you referring to, specifically? The ARM64 libwim-15.dll has the same dependencies as the x86_64 one, I believe. It only depends on standard Windows DLLs (ntdll, msvcrt, advapi32, user32, kernel32).