From: Max Vilimpoc Date: Sat, 5 Sep 2026 22:48:57 +0000 (+0200) Subject: dotfiles: fix two architecture bugs a real ARM64 run exposed X-Git-Url: https://vilimpoc.org/repos/dotfiles/commitdiff_plain/fbe899b67d263a1ae5404d3ed25f5f091c3d2c1e?ds=inline dotfiles: fix two architecture bugs a real ARM64 run exposed Running setup-windows.bat end to end on an ARM64 box turned up two packages that quietly did the wrong thing, and one bug in the audit that was hiding a third. WinMerge installed as x64 on ARM64. Upstream publishes the ARM64 build as a MACHINE-scope installer and the x64 build as a PER-USER one, so an unelevated winget lets its scope preference beat its architecture preference and silently picks the emulated x64. Ask for --architecture arm64 first and fall back to the default, so an administrator run gets the native build and a standard-user run still gets a working diff tool. LLVM does not fail when it cannot write to Program Files - it relocates. The NSIS installer falls back to a per-user directory (observed at %USERPROFILE%\Documents\LLVM) and winget still reports "Successfully installed", so the compiler is genuinely present, genuinely native, and findable by nothing. Its silent install also does not take the add-to-PATH option. New LlvmPath step looks in that fallback as well as the usual roots, reports the architecture, notes when the location means the install was not machine-wide, and appends the directory to the user PATH. Appended rather than prepended: this is a second compiler kept alongside MSVC and should not quietly win a clang-cl meant for Visual Studio's copy. The audit resolved labelled entries PATH-first, so with upstream LLVM on the PATH the "clang-cl.exe (VS)" row answered with the upstream compiler and reported Visual Studio's as present when it was absent. A labelled entry names one specific copy and is now resolved only from its explicit candidates; unlabelled entries still resolve PATH-first, because for those the question is which binary a build would actually invoke. Also record what a standard user cannot provision. The elevated half needs an account that can elevate, and several packages in the non-elevated section are per-user in name only: the .NET SDK (exit 5), CMake and Android GPU Inspector (MSI 1603) and OpenCppCoverage (self-elevating) all fail without an administrator. Verified on ARM64: cmake, ninja, git, python, ssh, xperf, MSBuild and cl.exe all native; both compilers build a native ARM64 binary through the Ninja generator - MSVC 1950 and clang 22.1.8, each reporting target ARM64. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Ak6VzfGyaocrykX1LhNMwt --- diff --git a/README.md b/README.md index f897f4b..323fe36 100644 --- a/README.md +++ b/README.md @@ -324,6 +324,34 @@ Anything emulated with a listed reason prints as expected. Anything emulated *without* one is called out, with a remedy where a native build exists — which is how the `ninja` problem below was found. +### You need an administrator for the elevated half + +`setup-windows.bat` assumes whoever runs it **can elevate**. If the account is a +standard user, the UAC prompt is an over-the-shoulder *credential* prompt rather +than a Yes/No, and declining it leaves the elevated half unrun — no Visual Studio +components (so no `clang-cl`), no WDK, no `rsync`, no `sshd`. The batch reports +`ELEVATED SETUP FAILED` and prints no log, because none was written. + +The same applies to several packages in the *non-elevated* section, which are +per-user only in name: the .NET SDK (`exit 5`), CMake and Android GPU Inspector +(MSI `1603`), and OpenCppCoverage (its installer self-elevates) all fail for a +standard user. Sign in to an administrator account to provision, or expect that +subset to be missing. + +Two consequences worth knowing rather than rediscovering: + +- **LLVM does not fail — it relocates.** Its NSIS installer targets + `%ProgramFiles%\LLVM`, and when it cannot write there it silently falls back to + a per-user directory (observed: `%USERPROFILE%\Documents\LLVM`) while winget + still reports *Successfully installed*. The compiler is genuinely there and + native; nothing can find it. The `LlvmPath` step looks in that fallback, puts + the directory on the user `PATH`, and says so. +- **WinMerge silently downgrades to x64.** Upstream publishes ARM64 as a + **machine-scope** installer and x64 as a **per-user** one, so an unelevated + winget lets its scope preference beat its architecture preference. The batch + now asks for `--architecture arm64` first and falls back, so an admin run gets + the native build and a standard-user run still gets a working one. + ### Two gotchas the audit surfaces - **Visual Studio bundles an x64 `ninja.exe` even on ARM64.** It matters more diff --git a/setup-windows-no-uac.ps1 b/setup-windows-no-uac.ps1 index 3b67f0f..1fd2c1f 100644 --- a/setup-windows-no-uac.ps1 +++ b/setup-windows-no-uac.ps1 @@ -40,7 +40,7 @@ param( # for several, dot-call the script or use -Command: # .\setup-windows-no-uac.ps1 -Skip BinSkim,GitConfig # powershell -File .\setup-windows-no-uac.ps1 -Skip BinSkim - [ValidateSet('WinMerge', 'VsWhere', 'BinSkim', 'GitConfig', 'NinjaPath', 'ArchAudit')] + [ValidateSet('WinMerge', 'VsWhere', 'BinSkim', 'GitConfig', 'NinjaPath', 'LlvmPath', 'ArchAudit')] [string[]] $Skip = @() ) @@ -421,6 +421,51 @@ function Set-NativeNinjaFirst { Add-ToUserPath (Split-Path $native -Parent) -Prepend } +function Add-LlvmToUserPath { + # Put the upstream LLVM's bin directory on the user PATH. + # + # Two reasons this needs a step rather than trusting the installer: + # + # 1. WHERE IT LANDS. LLVM's NSIS installer targets %ProgramFiles%\LLVM, and + # when it cannot write there - a standard user, no elevation - it does not + # fail. It silently falls back to a per-user directory, observed as + # %USERPROFILE%\Documents\LLVM, and winget still reports "Successfully + # installed". So the package is registered, the compiler is genuinely + # there and native, and nothing can find it. + # 2. PATH. The installer's "add to PATH" option is not taken in a silent + # install, so clang-cl is not a command afterwards either way. + # + # Appended, not prepended: this is a second compiler kept deliberately + # alongside MSVC, and it should not quietly win a `clang-cl` that some script + # meant for Visual Studio's copy. Note VS does NOT put its own + # VC\Tools\Llvm on the PATH (its clang-cl is reached through CMake's + # -T ClangCL), so there is no collision to lose here. + Write-Step 'Upstream LLVM on the user PATH' + $candidates = @( + (Join-Path $env:ProgramFiles 'LLVM\bin') + (Join-Path ${env:ProgramFiles(x86)} 'LLVM\bin') + (Join-Path $env:LOCALAPPDATA 'Programs\LLVM\bin') + (Join-Path ([Environment]::GetFolderPath('MyDocuments')) 'LLVM\bin') + (Join-Path $env:USERPROFILE 'Documents\LLVM\bin') + ) + $dir = $candidates | Where-Object { Test-Path (Join-Path $_ 'clang-cl.exe') } | Select-Object -First 1 + if (-not $dir) { + Write-Host ' Not installed (winget install LLVM.LLVM); Visual Studio''s own clang-cl is unaffected.' -ForegroundColor DarkGray + return + } + $exe = Join-Path $dir 'clang-cl.exe' + $mach = Get-PEMachine $exe + Write-Host " $exe ($mach)" + if ($IsArm64 -and $mach -ne 'ARM64') { + Write-Warning "This LLVM is $mach, not ARM64. winget install LLVM.LLVM should resolve to the -woa64 build on this host." + } + if ($dir -notmatch [regex]::Escape($env:ProgramFiles)) { + Write-Host ' Note: not under Program Files - the installer fell back to a per-user' -ForegroundColor Yellow + Write-Host ' location because it could not write there. Re-run elevated for a machine-wide install.' -ForegroundColor Yellow + } + Add-ToUserPath $dir +} + function Get-PEMachine { # Architecture of a PE, read straight from the COFF header: the 2 bytes at # the e_lfanew offset + 4. Cheap, and it answers the only question that @@ -513,8 +558,9 @@ function Invoke-ArchAudit { # puts the native copy first; this is the check that it worked. $Remedies = @{ 'ninja.exe' = 'Visual Studio bundles an x64 ninja. Install the native one (winget install Ninja-build.Ninja) and re-run - the NinjaPath step puts its directory at the front of the user PATH.' - 'cmake.exe' = 'Install the native build with: winget install Kitware.CMake' - 'clang-cl.exe' = 'Install the upstream native LLVM with: winget install LLVM.LLVM' + 'cmake.exe' = 'Install the native build with: winget install Kitware.CMake (its MSI is machine-scope, so it needs an administrator).' + 'clang-cl.exe' = 'Install the upstream native LLVM with: winget install LLVM.LLVM' + 'WinMergeU.exe' = 'Upstream ships ARM64 as a MACHINE-scope installer and x64 as per-user, so an unelevated winget picks x64. Re-run as an administrator to get: winget install WinMerge.WinMerge --architecture arm64' } $vs = $null @@ -531,7 +577,13 @@ function Invoke-ArchAudit { 'pwsh.exe' = @() 'cmake.exe' = @((Join-Path $env:ProgramFiles 'CMake\bin\cmake.exe')) 'ninja.exe' = @() - 'clang-cl.exe' = @((Join-Path $env:ProgramFiles 'LLVM\bin\clang-cl.exe')) + # Upstream LLVM. The Documents path is not a typo - see Add-LlvmToUserPath + # for why an unelevated install lands there. + 'clang-cl.exe' = @( + (Join-Path $env:ProgramFiles 'LLVM\bin\clang-cl.exe') + (Join-Path $env:LOCALAPPDATA 'Programs\LLVM\bin\clang-cl.exe') + (Join-Path ([Environment]::GetFolderPath('MyDocuments')) 'LLVM\bin\clang-cl.exe') + ) 'dotnet.exe' = @((Join-Path $env:ProgramFiles 'dotnet\dotnet.exe')) 'WinMergeU.exe' = @((Join-Path $env:ProgramFiles 'WinMerge\WinMergeU.exe'), (Join-Path ${env:ProgramFiles(x86)} 'WinMerge\WinMergeU.exe')) 'BinSkim.exe' = @((Join-Path $BinSkimDir 'BinSkim.exe')) @@ -559,11 +611,21 @@ function Invoke-ArchAudit { $native = if ($IsArm64) { 'ARM64' } else { 'x64' } $unexpected = @() foreach ($name in $targets.Keys) { - # PATH first - that is the binary a build would actually invoke - then the - # explicit candidates. The bare exe name is stripped of any " (label)". - $exe = ($name -split ' ')[0] - $path = Resolve-OnPath $exe - if (-not $path) { $path = $targets[$name] | Where-Object { $_ -and (Test-Path $_) } | Select-Object -First 1 } + # A LABELLED entry - "clang-cl.exe (VS)" - names one specific copy, so it + # is resolved ONLY from its explicit candidates. Falling back to the PATH + # there would silently answer with a different installation of the same + # tool: with upstream LLVM on the PATH, the "(VS)" row reported the + # upstream compiler and so claimed Visual Studio's was present when it was + # not. Unlabelled entries still resolve PATH-first, because for those the + # question is which binary a build would actually invoke. + $exe = ($name -split ' ')[0] + $isPinned = $name -ne $exe + if ($isPinned) { + $path = $targets[$name] | Where-Object { $_ -and (Test-Path $_) } | Select-Object -First 1 + } else { + $path = Resolve-OnPath $exe + if (-not $path) { $path = $targets[$name] | Where-Object { $_ -and (Test-Path $_) } | Select-Object -First 1 } + } if (-not $path) { Write-Host (" {0,-22} {1}" -f $name, '- not installed') -ForegroundColor DarkGray; continue } $mach = Get-PEMachine $path @@ -605,6 +667,7 @@ $steps = [ordered]@{ BinSkim = { Install-BinSkim } GitConfig = { Set-GlobalGitConfig } NinjaPath = { Set-NativeNinjaFirst } + LlvmPath = { Add-LlvmToUserPath } # Last on purpose: it reports on what the steps above (and the winget installs # in setup-windows.bat) actually put on the box. ArchAudit = { Invoke-ArchAudit } diff --git a/setup-windows.bat b/setup-windows.bat index 05e65eb..b9e4752 100644 --- a/setup-windows.bat +++ b/setup-windows.bat @@ -47,7 +47,25 @@ winget install Git.Git winget install Microsoft.DotNet.SDK.10 winget install Microsoft.PowerShell Microsoft.Sysinternals.ProcessExplorer Microsoft.Sysinternals.ProcessMonitor Microsoft.Sysinternals.SDelete Microsoft.VisualStudioCode Microsoft.WindowsTerminal winget install Python.Python.3.13 -winget install WinMerge.WinMerge + +@rem WinMerge is the one package here where winget's own preference order picks +@rem the WRONG architecture, and it is worth knowing why: upstream publishes the +@rem ARM64 build as a MACHINE-scope installer (WinMerge--ARM64-Setup.exe) and +@rem the x64 build as a PER-USER one (WinMerge--x64-PerUser-Setup.exe). Run +@rem unelevated, winget's scope preference beats its architecture preference and +@rem you silently get the emulated x64 build. +@rem +@rem So ask for arm64 explicitly, and fall back to the default when that cannot be +@rem installed - which is exactly the standard-user case, where the machine-scope +@rem installer has nowhere to go. The fallback is the x64 build under emulation: +@rem a diff tool is not a hot path, and a working WinMerge beats none. The +@rem architecture audit at the end of setup-windows-no-uac.ps1 reports which one +@rem you ended up with. +if "%IS_ARM64%"=="1" ( + winget install WinMerge.WinMerge --architecture arm64 || winget install WinMerge.WinMerge +) else ( + winget install WinMerge.WinMerge +) @rem --- Build drivers, standalone and native --- @rem