ARM64 Support

[synchronicity]

(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.)

[zipmagic]

Thanks for the prompt response.

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.

That said, I haven't regression tested on older than Windows 8.1 (due to it being the minimum WIMBOOT target for us here).

However I'd have high hopes that it'd work just fine, now that you've addressed the static build bug.

[zipmagic]

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_64 binaries from https://wimlib.net/downloads/index.html, as I've still been building those on Linux, not in MSYS2.

I don't have an explanation for why you saw api-ms-win-crt-convert-l1-1-0.dll being required. I'm not seeing that.

I tested the builds on Windows Server 2022, not on Windows 8.1 as you did, though. Maybe that makes a difference.

Please note that it's possible to clone the wimlib repository on GitHub, and then run the GitHub Actions workflow, which builds all the Windows builds reproducibly using the windows-latest GitHub Actions runner which currently uses Windows Server 2022. That can be used as a more-reproducible alternative to doing the build locally.

The file sizes didn't change at all, so I'm thinking this didn't quite help.

Retesting with the block set to:

Code: Select all

	if "$cc" --version | grep -q '(GCC)'; then
		configure_args+=("CC=$cc -static -static-libgcc -static-libstdc++")
	fi

Again, the file sizes were unchanged. I retested just to be positive, and sadly again the same error on 32 bit Windows 8.1:

---------------------------
System Error
---------------------------
The program can't start because libgcc_s_dw2-1.dll is missing from your computer. Try reinstalling the program to fix this problem.
---------------------------
OK
---------------------------

Any thoughts on what else might be attempted here?

[synchronicity]

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?

[synchronicity]

Code: Select all

if "$cc" --version | grep -q '(GCC)'; then
        configure_args+=("CC=$cc -static -static-libgcc -static-libstdc++")
fi

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

[zipmagic]

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'm already building on Windows 11, do you mean I should try building on Windows 8.1 instead?

[zipmagic]

Code: Select all

if "$cc" --version | grep -q '(GCC)'; then
        configure_args+=("CC=$cc -static -static-libgcc -static-libstdc++")
fi

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

To clarify after doing the git pull, this is the code I ended up with:

Code: Select all

	if ! "$cc" --version | grep -q -i 'clang'; then
		configure_args+=("CC=$cc -static-libgcc")

And is this what I am supposed to replace it with?

Code: Select all

	if "$cc" --version | grep -q '(GCC)'; then
		configure_args+=("CC=$cc -static -static-libgcc -static-libstdc++")

Again to clarify, I've tried builds with both gcc and clang with both combinations above (4 in total) and did not end up with binaries that worked without dependencies in any scenario in the x86 Windows 8.1 test case. clang fails on Windows 8.1 x86 and amd64 in both cases, too.

[synchronicity]

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 include in your bug report the commit ID you're using. And preferably do the build on the latest version of Windows (matching what I've tested and what the GitHub Actions workflow does), so that we can rule out a difference in that area. Thanks.

[zipmagic]

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 include in your bug report the commit ID you're using. And preferably do the build on the latest version of Windows (matching what I've tested and what the GitHub Actions workflow does), so that we can rule out a difference in that area. Thanks.

I do regret the false positive - it seems (retesting after the latest git pull which did up the version somehow [so as not to discount the possibility of an interim fix at your end in the meanwhile]) the changes made to WIMLIB for driver support were to account for these new odd DLL dependencies. We'll just have to take them up with the driver developer.