Nim GC Mode Switching Affects Linked Object Files and Manual Memory Portability

Answer

No. A `gc` pragma or `--gc` flag is compiler configuration, not a patch for object files already on disk. Recompiling one source file applies the new collector mode to that translation unit only; sibling object files retain the allocation calls, write barriers, finalizer registrations, and stack-scanning assumptions they were compiled with. For a consistent whole-program collector, recompile every Nim module that allocates, traces, finalizes, or references GC-managed objects, then relink. `gc none` is likewise not portable across platforms: object files are tied to a target OS, architecture, and ABI, and differing stack-scanning implementations require a fresh target-specific build and test pass.

Confirmed behavior and release-specific uncertainty

Assumptions: standard static linking of the Nim runtime and no link-time optimization that merges GC models across object files.

Steps for this case

1. List every Nim module that allocates, traces, finalizes, or stores GC-managed pointers.
2. Recompile all listed modules with a single identical GC setting.
3. Relink the executable.
4. Do not copy object files between operating systems, architectures, or ABIs.
5. For `gc none`, rebuild for each target and test manual allocations, cross-module pointer escapes, exceptions, and finalizers on that target.

Verification

Inspect object files for collector references before and after a selective rebuild:

nm module.o | grep -i gc

Unchanged GC references in the old object confirm the pragma did not rewrite it. Rebuild all modules with one identical `--gc` value and compare behavior; if crashes disappear, a full rebuild was required.

Missing diagnostic

Provide your exact Nim version and whether you use a procedure-scoped `{.gc: ...}` pragma or the global `--gc` flag. That detail determines whether the rebuild scope covers annotated procedures only or whole modules, so it changes the recommendation.