You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Link AOT output against static CRT (/MT[d]) everywhere
The generated exe/dll previously linked the dynamic CRT (ucrt[d] +
msvcrt[d]) while the prebuilt LLVM/MLIR libs, the TypeScript runtime
libs and gc.lib all use the static CRT (/MT[d]). Mixing the two gives
the generated program a separate heap and stdout buffer from those
libs, crashing at startup/teardown (0xC0000005), notably for
-emit=dll/-shared and import tests.
Switch the Windows AOT link to the static CRT import names
(libucrt[d] + libcmt[d] + libvcruntime[d]) to match, and drop the
msvcrt[d] DLL-resolution branch that is no longer needed once the
GC/runtime libs are linked statically.
NOTE: requires the 3rdParty gc and LLVM packages to be the /MT builds.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Update GC version to 8.2.12 in build scripts and download links
* Isolate Windows shared tests in a per-test working directory
The Windows shared-test bat wrote fixed-name artifacts (<stem>.obj,
<stem>.dll, <stem>.lib) directly in the shared test/tester cwd, while
the imported-module stem is not unique across test variants - e.g.
decl_class.ts feeds the -shared, -compile-time and -jit variants, and
export_vars2.ts feeds two variants. Under `ctest -j` these run
concurrently and stomp/delete each other's artifacts, causing random
failures (e.g. test-compile-shared-decl-emit-class,
test-compile-shared-export-import-vars-2).
Port the per-test WORKDIR isolation the Linux branch already uses:
create a unique <tempname>_wd dir, cd into it, build/link/run there
(the shared lib keeps its real <stem> name needed for import
resolution but can no longer collide), write .txt/.err to the parent
dir the runner reads from, then remove the dir.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
0 commit comments