Linking

addRuntimeLibraries (lib/Frontend/Driver.cpp) adds -u malloc libweavec_alloc.a libweavec_rt.a to every link job of an enforcing build that targets the host, before the first library of the line, and -lpthread on Linux. An archive member is linked only when referenced, except the allocator, which -u forces in. Missing archives are an error: cannot find the WeaveC runtime (libweavec_rt.a, libweavec_alloc.a), which an enforcing link carries (-fweavec-checks=none builds without it).

runtimeObstacle reads the command line for a reason the build cannot use the runtime: -ffreestanding; -nostdlib, -nodefaultlibs or -nolibc; a sanitizer that replaces the allocator (address, hwaddress, memory, thread, leak, kernel-address); or a target other than 64-bit Darwin or Linux. The units are then compiled without guards, as under -fweavec-checks=none, and the link prints weavec-cc: note: building without the WeaveC runtime (<reason>): memory accesses are not guarded.

When an input of the link defines a symbol that libweavec_alloc.a defines strongly (allocatorDefinedBy reads the set from the archive itself), dropAllocatorIfDefined takes the archive and its -u off the line and prints a note: the program keeps its allocator, its heap is untracked (unless it poisons it through ASan’s interface), guards pass on it, and releases are not validated. Stack and global objects are still guarded.

A Darwin link with -flto gets -lto_library naming the libLTO of the LLVM WeaveC was built with, when the driver’s default does not exist.