Inventory: every way the native engine is deficient
The native engine (reld, the wild fork) is deliberately narrow — it links ordinary ELF fast and owns one capability (NativeControl). Everything else is either routed to the bundled lld bridge, silently ignored, warned, or rejected. This is the complete list as of this writing, sourced from the code.
1. Capabilities routed to ld.lld (native engine does not implement)
crates/reld-core/src/bridge.rs — NATIVE_RELD_CAPABILITIES = [NativeControl]; these seven Capability values are the native gaps that BR-6 routes to the ELF lld engine:
- LTO — ThinLTO / FullLTO. Native engine owns zero LTO codegen.
- ICF — identical code folding (
--icf).
- Discard-all —
-x / --discard-all (discarding local symbols).
- Fatal warnings —
--fatal-warnings.
- Color diagnostics —
--color-diagnostics.
- Version-script undefined-symbol policy —
--undefined-version / --no-undefined-version.
- Cortex-A53 erratum 843419 fixups.
2. Whole-format gaps (native is ELF-only)
3. Silently-ignored flags (semantics dropped, no warning)
SILENTLY_IGNORED_FLAGS in args/elf.rs — accepted as no-ops, so the requested behavior is silently lost:
--start-group / --end-group (cycle resolution not needed)
--nostdlib (TODO: no built-in search paths yet)
--no-undefined-version (TODO)
--fatal-warnings (TODO)
--color-diagnostics
--undefined-version (TODO)
--sort-common
--stats
- short
-( / -) (group delimiters)
4. Flags ignored in the native path (and delegated to lld)
IGNORED_FLAGS — --fix-cortex-a53-835769, --fix-cortex-a53-843419, --discard-all, -x. The native engine does not act on these itself; they fall through to the capability routing.
5. Unsupported flag values (warned or rejected)
-m <emulation> other than the six supported targets (elf_x86_64, elf_x86_64_sol2, aarch64elf, aarch64linux, elf64lriscv, elf64loongarch, elf64lppc) → hard error ("not yet supported").
- Unknown
-z <option> values → warned and dropped.
--pack-dyn-relocs=android / non-relr values → warned and dropped.
--icf=<value> values other than the routable one → warned and dropped.
--sort-section=<value> other than name / alignment → warned and dropped.
6. Deferred / explicit non-goals
- Native (Thin)LTO — stretch goal, not shipped; the product LTO path is the lld bridge.
- PGO / BOLT interaction — out of scope for the native engine.
- Cross-machine / cross-toolchain reproducible builds — not a release guarantee.
- Native Windows & macOS backends — "future work", bridge-only today.
- macOS raw throughput —
ld_prime is 1.4–2× faster than ld64.lld; the macOS pitch is incremental + open implementation, not speed.
Net
The native engine's positive capability set is fast ordinary ELF linking + incremental warm relink. For anything in the lists above, reld either delegates to lld (correct but lld-speed) or drops/ignores the flag (silent), or errors. Any item here that a real-world link actually needs is therefore either a correctness hand-off to lld or a silently-missing feature — worth triaging into "route to lld" vs "silently ignore" vs "implement natively".
Inventory: every way the native engine is deficient
The native engine (
reld, the wild fork) is deliberately narrow — it links ordinary ELF fast and owns one capability (NativeControl). Everything else is either routed to the bundledlldbridge, silently ignored, warned, or rejected. This is the complete list as of this writing, sourced from the code.1. Capabilities routed to
ld.lld(native engine does not implement)crates/reld-core/src/bridge.rs—NATIVE_RELD_CAPABILITIES = [NativeControl]; these sevenCapabilityvalues are the native gaps that BR-6 routes to the ELFlldengine:--icf).-x/--discard-all(discarding local symbols).--fatal-warnings.--color-diagnostics.--undefined-version/--no-undefined-version.2. Whole-format gaps (native is ELF-only)
lld-link(rust-lld -flavor link), not native (issue P3: PE/COFF backend, MinGW (windows-gnu) ABI #7).ld64.lld(rust-lld -flavor darwin), not native (issue P4: Mach-O backend, aarch64-apple-darwin #8).3. Silently-ignored flags (semantics dropped, no warning)
SILENTLY_IGNORED_FLAGSinargs/elf.rs— accepted as no-ops, so the requested behavior is silently lost:--start-group/--end-group(cycle resolution not needed)--nostdlib(TODO: no built-in search paths yet)--no-undefined-version(TODO)--fatal-warnings(TODO)--color-diagnostics--undefined-version(TODO)--sort-common--stats-(/-)(group delimiters)4. Flags ignored in the native path (and delegated to lld)
IGNORED_FLAGS—--fix-cortex-a53-835769,--fix-cortex-a53-843419,--discard-all,-x. The native engine does not act on these itself; they fall through to the capability routing.5. Unsupported flag values (warned or rejected)
-m <emulation>other than the six supported targets (elf_x86_64,elf_x86_64_sol2,aarch64elf,aarch64linux,elf64lriscv,elf64loongarch,elf64lppc) → hard error ("not yet supported").-z <option>values → warned and dropped.--pack-dyn-relocs=android/ non-relrvalues → warned and dropped.--icf=<value>values other than the routable one → warned and dropped.--sort-section=<value>other thanname/alignment→ warned and dropped.6. Deferred / explicit non-goals
ld_primeis 1.4–2× faster thanld64.lld; the macOS pitch is incremental + open implementation, not speed.Net
The native engine's positive capability set is fast ordinary ELF linking + incremental warm relink. For anything in the lists above, reld either delegates to
lld(correct but lld-speed) or drops/ignores the flag (silent), or errors. Any item here that a real-world link actually needs is therefore either a correctness hand-off to lld or a silently-missing feature — worth triaging into "route to lld" vs "silently ignore" vs "implement natively".