dodox/FEnigma
dodox/FEnigma
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Correct the ICE80 fix: -arch x64 on candle.exe, not heat.exe -platform

Browse Source 
The previous fix (heat.exe -platform x64) was wrong -- re-verified
live with the corrected build.bat confirmed actually deployed to the
VM (ruling out a stale-copy repeat of the earlier watcher bug),
identical ICE80 "32BitComponent uses 64BitDirectory" failures on every
single harvested component. WiX v3's heat.exe -platform flag only
affects registry-key harvesting, it never stamps Win64="yes" on
components.

Real fix: -arch x64 on candle.exe, the compile step, not the harvest
step -- sets the default Win64/Platform for every component compiled
from either source file (hand-authored product.wxs or harvested
files.wxs), the standard WiX v3 way to make a whole package
consistently 64-bit. Kept the harmless-but-insufficient heat.exe flag
too.

Not yet re-verified live -- next run should confirm a real .msi.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Dominik Moritz Roth 2026-08-13 23:00:45 +02:00
parent d3246328e8
commit d66b881239
2 changed files with 33 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
TODO.md
View File

@ -309,16 +309,26 @@ each confirmed live against the real VM, not just read off a diff:
- [ ] ...and then failed for a REAL reason right at the very end:
`light.exe`'s ICE80 validation rejected essentially every
harvested file -- "This 32BitComponent ... uses 64BitDirectory".
`heat.exe`'s harvest command had no `-platform x64`, so every
component it generated defaulted to 32-bit, while
`product.wxs`'s own `INSTALLFOLDER` is correctly under
`ProgramFiles64Folder` (a 64-bit mingw64 toolchain is what's
actually being packaged) -- a real, on-disk mismatch, not a
transient VM issue. Fixed: added `-platform x64` to `build.bat`'s
`heat.exe` invocation. NOT YET re-verified against a live build
(found right as this session's VM time/cycles were already
heavily spent -- next run should get all the way to a real
`.msi`, but that's still a claim, not yet a confirmed result).
actually being packaged), but nothing was making the components
agree -- a real, on-disk mismatch, not a transient VM issue.
First fix attempt (`-platform x64` on `heat.exe`'s harvest) was
WRONG -- re-verified live, identical ICE80 failures afterward
(confirmed the corrected `build.bat` had actually reached the VM
this time, ruling out a stale-copy repeat of the earlier watcher
bug). WiX v3's `heat.exe -platform` only affects registry-key
harvesting, it never stamps `Win64="yes"` on components. Real
fix: `-arch x64` on `candle.exe` (the COMPILE step, not the
harvest step) -- sets the default Win64/Platform for every
component compiled from either source file, hand-authored
(`product.wxs`) or harvested (`files.wxs`) alike, the standard
WiX v3 way to make a whole package consistently 64-bit. Kept the
harmless-but-insufficient `-platform x64` on `heat.exe` too.
Applied, NOT YET re-verified live (this session's VM time is
long since past reasonable for one sitting -- next run should
confirm a real `.msi`, but treat that as still unconfirmed until
it actually happens).
Once confirmed, revisit the still-slow `light.exe` step itself
(the ~1GB+ bulk-copied mingw64 dist tree, see README's own "not
lean" note) as a separate, real perf follow-up -- 40 minutes for

21
packaging/windows/oem/build.bat
View File

@ -49,11 +49,12 @@ REM here (see this file's top-of-file note).
robocopy C:\msys64\mingw64 C:\build\dist\mingw64 /e /xd include share\doc share\man share\gtk-doc /nfl /ndl /njh /njs >> %LOG% 2>&1
echo [build.bat] harvesting WiX components ... >> %LOG%
REM -platform x64: confirmed live (real light.exe run, not guessed) --
REM without it heat.exe defaults every harvested component to 32-bit,
REM which light.exe's ICE80 validation then rejects wholesale (~every
REM single harvested file) once it's placed under INSTALLFOLDER, a
REM 64-bit directory (this is a 64-bit mingw64 toolchain being packaged).
REM -platform x64 alone is NOT enough (confirmed live: still every
REM component ICE80'd afterward) -- WiX v3 heat.exe's -platform flag
REM doesn't actually stamp Win64="yes" on harvested components itself,
REM it only affects registry-key harvesting. Kept anyway (harmless,
REM correct in spirit), but the real fix is candle.exe's -arch x64
REM below, see its own comment.
C:\wix\heat.exe dir C:\build\dist -platform x64 -cg AppFiles -gg -scom -sreg -sfrag -srd -sw5150 -dr INSTALLFOLDER -var var.DistDir -out C:\build\files.wxs >> %LOG% 2>&1
if errorlevel 1 (
echo [build.bat] FAILED: heat.exe harvest failed >> %LOG%
@ -65,7 +66,15 @@ if errorlevel 1 (
copy /y C:\FenigmaBuild\product.wxs C:\build\product.wxs >nul
echo [build.bat] compiling (candle) ... >> %LOG%
C:\wix\candle.exe -dDistDir=C:\build\dist -dAppVersion=%APPVER% -out C:\build\ C:\build\product.wxs C:\build\files.wxs >> %LOG% 2>&1
REM -arch x64: the actual fix for the ICE80 "32BitComponent uses
REM 64BitDirectory" failure (confirmed live -- heat.exe's own -platform
REM x64 above does NOT set this, only affects registry harvesting).
REM -arch sets the default Win64/Platform for every component compiled
REM from EITHER source file, hand-authored (product.wxs) or harvested
REM (files.wxs) alike, without needing per-component authoring -- the
REM standard WiX v3 way to make a whole package consistently 64-bit,
REM matching product.wxs's own ProgramFiles64Folder.
C:\wix\candle.exe -arch x64 -dDistDir=C:\build\dist -dAppVersion=%APPVER% -out C:\build\ C:\build\product.wxs C:\build\files.wxs >> %LOG% 2>&1
if errorlevel 1 (
echo [build.bat] FAILED: candle.exe failed >> %LOG%
copy %LOG% Z:\build.log.failed >nul