Runtime crash: undefined behavior when linking ARC and ORC compiled modules

Answer

No. A Nim library compiled with --gc:arc must not be linked into an executable compiled with --gc:orc. Mixing the two memory-management strategies is undefined behavior and is not considered safe.

Confirmed facts

• Nim allows a GC choice per compilation via --gc. Mixing strategies across translation units is cautioned as capable of causing runtime crashes or memory-safety violations.
• The system linker emits no warning for mismatched Nim GC strategies because GC policy is not part of the object-file ABI the linker checks.
• There is no supported linker flag or pragma that reconciles ARC and ORC modules after compilation.
• No compile-time or link-time diagnostic currently prevents inadvertent mixing in general builds.

Likely explanation

ORC optimizes away reference-count operations that ARC assumes are present. Objects that cross the ARC/ORC boundary can therefore be freed too early, double-freed, or never released. Cycle collection is not guaranteed to run consistently across the boundary because each side may observe different reference counts.

Concrete symptoms are undefined and version-dependent. Reported classes of failure include segmentation faults or access violations from use-after-free, double-free aborts, heap corruption, and silent memory leaks. Exact behavior cannot be predicted.

Steps for this case

1. Rebuild all Nim modules in the program with a single consistent --gc value. There is no safe linker-level remedy for a mismatch.
2. Do not pass Nim traced objects such as ref, ptr, seq, or string across an ARC/ORC boundary. Ownership semantics differ.
3. If a C boundary is required, expose only plain C types and manually manage ownership. Avoid Nim GC-managed references on both sides.

Verification approach: build a minimal reproduction with one side ARC and one side ORC, pass a traced object between them, and run under AddressSanitizer or Valgrind to observe crashes or leaks. Rebuilding the whole program with one --gc value and seeing the crash disappear isolates the mismatch as the cause.

One missing detail that changes the recommendation: the Nim compiler version and whether the library is imported as Nim code or accessed via a C FFI. Current verification is required to confirm whether your toolchain emits any GC-mismatch diagnostic, as behavior is version-dependent.