zig

commit 3e7708b02b48595f004083b17a05363d9fb2fa57 (tree)
parent b16c094926cf659e144cbcbed6c69cd820c5ff9f
Author: Alex Rønne Petersen <alex@alexrp.com>
Date:   Sat, 26 Apr 2025 16:51:16 +0200

link.Elf: Skip invoking LLD for `zig build-obj` for unsupported targets.

LLD doesn't support these yet. Doing this hack will at least allow basic
experimentation for these targets.

Diffstat:
M
src/link/Elf.zig
 | 
13
++++++++++++-

1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/link/Elf.zig b/src/link/Elf.zig
@@ -1663,7 +1663,18 @@ fn linkWithLLD(self: *Elf, arena: Allocator, tid: Zcu.PerThread.Id, prog_node: s
     // copy when generating relocatables. Normally, we would expect `lld -r` to work.
     // However, because LLD wants to resolve BPF relocations which it shouldn't, it fails
     // before even generating the relocatable.
-    if (output_mode == .Obj and (comp.config.lto != .none or target.cpu.arch.isBpf())) {
+    //
+    // For m68k, we go through this path because LLD doesn't support it yet, but LLVM can
+    // produce usable object files.
+    if (output_mode == .Obj and
+        (comp.config.lto != .none or
+            target.cpu.arch.isBpf() or
+            target.cpu.arch == .lanai or
+            target.cpu.arch == .m68k or
+            target.cpu.arch.isSPARC() or
+            target.cpu.arch == .ve or
+            target.cpu.arch == .xcore))
+    {
         // In this case we must do a simple file copy
         // here. TODO: think carefully about how we can avoid this redundant operation when doing
         // build-obj. See also the corresponding TODO in linkAsArchive.