check-for-missing-dlls: fixes for ARM64#699
Conversation
`uname -m` outputs x86_64 on CLANGARM64, not aarch64, because the msys2-runtime currently has no aarch64 port. `uname -s` does know when we're running on ARM64, though. [1] Use that information to allow us to set MINGW_PREFIX based on `uname`. [1] msys2/msys2-runtime#238 Signed-off-by: Matthias Aßhauer <mha1993@live.de>
f078bad (check-for-missing-dlls: support running on Windows/ARM64, 2025-04-21) changed check-for-missing-dlls to only set ARCH when MINGW_PREFIX is empty and MSYSTEM is an unexpected value, but make-file-list expects ARCH to be set. Go back to always setting ARCH to meet that expectation. Signed-off-by: Matthias Aßhauer <mha1993@live.de>
make-file-list expects `aarch64` as the ARCH value on ARM64, not `x86_64`. Signed-off-by: Matthias Aßhauer <mha1993@live.de>
rimrul
force-pushed
the
check-for-missing-dlls-arm64-fixes
branch
from
12d52f4 to
049b727
Compare
MINGW_PREFIX doesn't have to be "mingw" followed by two digits anymore. We have "clangarm64" now and there are talks about potentially adding "ucrt64" to the mix in the near future. Account for prefixes that break old moulds. Signed-off-by: Matthias Aßhauer <mha1993@live.de>
interesting. |
This seems odd. Curl probably uses libnghttp.
These seem really odd.
This one seems to be just a missing |
Indeed. It's possible, of course, that they are usually only pulled in via GCC, but why are they there? If only I had a convenient way to spin up a Windows/ARM64 VM I could investigate a lot better :-(
Good point. |
@dscho happy to test some things on my Surface Pro X, but currently a bit time-constrained. I have the GfW arm64 SDK already installed on it. Do you mind giving me some instructions on what exactly you'd like to test? Thanks! |
@dennisameling Thank you for offering! But I think that I actually now have a relatively good way to let Copilot run in CI. So if there's any more problems, I will just add a step where Copilot gets a prompt and has to churn through all the remaining problems. It will run on the actual Actions runner and therefore will have a proper Windows/ARM64 environment that I lack. |
On ARM64, the MSYS2 `/usr/bin/objdump` cannot parse `pei-aarch64` PE files, and the `ldd` fallback (running under x86_64 WoW64 emulation) produces hopelessly incomplete results: only system DLLs loaded by ntdll show up while the actual PE import-table entries are invisible. This caused both false "missing" reports (from ldd self-references) and false "unused" reports (genuine dependencies that ldd simply could not see). Replace the ldd fallback with a small PowerShell script (`pe-imports.ps1`) that reads the PE import directory directly from the binary. This works on any PE architecture because it parses the well-defined PE data structures (DOS header, COFF/optional headers, section table, import descriptors) rather than trying to load the binary. The script outputs in `objdump -p` compatible format (file headers and `DLL Name:` lines), so the existing parser in `check-for-missing-dlls.sh` handles it without further changes. `powershell.exe` (Windows PowerShell 5.1) is available on every modern Windows installation, including the GitHub Actions ARM64 runners. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The unused-DLL exclusion regex for msalruntime variants was `msalruntime\(\|_x86\|arm64\)` which matches `msalruntimearm64` (no underscore) instead of the actual filename `msalruntime_arm64`. Add the missing underscore so the pattern correctly excludes `msalruntime_arm64.dll` from the unused-DLL check. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For lurkers, this commit implements that strategy that I was talking about: 628a5e1 |
|
And in case it was unclear why I run this Copilot experiment in a separate PR: The prerequisite token is stored as an Action secret, which is unavailable in cross-fork PRs' builds. |
On clangarm64, `libunwind.dll` and `libwinpthread-1.dll` are pulled in by the toolchain's package closure (`mingw-w64-clang-aarch64-libc++` brings `libunwind`, the clangarm64 runtime brings `libwinpthread-1`) but are not statically imported by any shipped binary. A scan of the PE import tables of all 602 shipped binaries on ARM64 found zero references to either DLL, neither in the regular import directory, in the delay-load directory, nor as raw string references. Exclude them from the file list on aarch64, matching the existing pattern used for `libssp` on platforms where it is no longer needed. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Windows API sets (`api-ms-win-crt-*.dll` and similar) are virtual DLL names resolved by the Windows loader at runtime. They are always provided by the OS and never need to be shipped. On Windows 11 ARM64 these stub DLLs live under `system32\downlevel\` rather than directly under `system32\`, so the script's system DLL enumeration did not find them, and every binary importing UCRT API sets was falsely flagged as "missing" the stubs. Rather than enumerating additional system directories, skip `api-ms-*` imports entirely: they are OS-provided by contract and cannot meaningfully be "missing" from a package. Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In MinGit mode, the two binaries that import `libc++.dll` (`pdftotext.exe` and `WhoUses.exe`) are both excluded from the file list. With `pe-imports.ps1` now correctly reading ARM64 PE imports, `check-for-missing-dlls.sh` flags `libc++.dll` as unused in MinGit because nothing in the MinGit set imports it. Add `libc++.dll` to the existing MinGit-only `grep -v` block, alongside `libgcc_s_seh` and `libjemalloc`. The full installer still ships it (`WhoUses.exe` and `pdftotext.exe` need it there). Assisted-by: Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
force-pushed
the
check-for-missing-dlls-arm64-fixes
branch
from
c459626 to
30d3d6e
Compare
3 participants
Our
check-for-missing-dllsworkflow in the git-sdk-arm64 repo currently does nothing. These fixes should make it work as expected.