Re: ARM64 Support
Posted: Wed Feb 07, 2024 6:42 am
(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.)
The file sizes didn't change at all, so I'm thinking this didn't quite help.synchronicity wrote: ↑Wed Feb 07, 2024 6:42 am 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.
Code: Select all
if "$cc" --version | grep -q '(GCC)'; then
configure_args+=("CC=$cc -static -static-libgcc -static-libstdc++")
fi
Any thoughts on what else might be attempted here?---------------------------
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
---------------------------
Why not do the build on one of those, then?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.
Code: Select all
if "$cc" --version | grep -q '(GCC)'; then
configure_args+=("CC=$cc -static -static-libgcc -static-libstdc++")
fi
I'm already building on Windows 11, do you mean I should try building on Windows 8.1 instead?synchronicity wrote: ↑Thu Feb 08, 2024 3:21 amWhy not do the build on one of those, then?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.
To clarify after doing the git pull, this is the code I ended up with:synchronicity wrote: ↑Thu Feb 08, 2024 3:30 amThat's also the old code, not the new code, so make sure you've run 'git pull'...Code: Select all
if "$cc" --version | grep -q '(GCC)'; then configure_args+=("CC=$cc -static -static-libgcc -static-libstdc++") fi
Code: Select all
if ! "$cc" --version | grep -q -i 'clang'; then
configure_args+=("CC=$cc -static-libgcc")
Code: Select all
if "$cc" --version | grep -q '(GCC)'; then
configure_args+=("CC=$cc -static -static-libgcc -static-libstdc++")
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.synchronicity wrote: ↑Sat Feb 10, 2024 5:36 pm 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.