cgo build failed when cc='zig cc'

[jiacai2050]

Zig Version

0.14.0-dev.6+0ba64e9ce

Steps to Reproduce and Observed Behavior

package main

// #include <stdio.h>
// #include <stdlib.h>
//
// static void myprint(char* s) {
//   printf("%s\n", s);
// }
import "C"
import "unsafe"

func main() {
	cs := C.CString("Hello from stdio")
	C.myprint(cs)
	C.free(unsafe.Pointer(cs))
}

Given this file, compile with

CC='zig cc' go build main.go

it will throw following errors on my machine:

# command-line-arguments
/Users/jiacai/.asdf/installs/golang/1.22.4/go/pkg/tool/darwin_arm64/link: running zig failed: exit status 1
error: symbol _runtime.covctrs not attached to any (sub)section
    note: while parsing /var/folders/50/12rf3hkj2n10whhf8l63nnyh0000gn/T/go-link-3691128890/go.o

Expected Behavior

Build OK

$ go version
go version go1.22.4 darwin/arm64

[JamesParrott]

I can reproduce this with Zig 0.13, on both MacOS 12 and 13.

Run go env -w "CC=zig cc"
  go env -w "CC=zig cc"
  go build -o hello main.go
  shell: /bin/bash -e {0}
# command-line-arguments
/Users/runner/hostedtoolcache/go/1.22.3/x64/pkg/tool/darwin_amd64/link: running zig failed: exit status 1
error: symbol _runtime.covctrs not attached to any (sub)section
    note: while parsing /var/folders/vy/h7r6h43j203gstfh6fj9_tyh0000gn/T/go-link-1939405894/go.o

https://github.com/JamesParrott/CGo_Zig_bug/actions/runs/9445915792/job/26014475941

On MacOS 14, compilation was thwarted by something different (see below). I think the free MacOS 14 runners might be ARM, possibly even Apple-M1. CGo plus Zig seems to require more configuration on MacOS than on Ubuntu or Windows, whatever the host arch is.

  go env -w "CC=zig cc"
  go build  -o hello main.go
  shell: /bin/bash -e {0}
# runtime/cgo
error: unknown target CPU 'westmere'
...
(list of cpu names)

[dan-smetana]

@kubkon

[dan-smetana]

@kubkon For me this happens when targeting x86_64 as well.

[kubkon]

@kubkon For me this happens when targeting x86_64 as well.

Fixed labels, thanks.

[dan-smetana]

I'm sure this is not the proper way to fix this, but this patch (essentially doing the reverse of @kubkon 's commit that introduced this error) does result in fully functional binaries for me.

diff --git a/src/link/MachO/Object.zig b/src/link/MachO/Object.zig
index c856c65d4e..0b246a22fa 100644
--- a/src/link/MachO/Object.zig
+++ b/src/link/MachO/Object.zig
@@ -647,7 +647,7 @@ pub fn findAtom(self: Object, addr: u64) ?Atom.Index {
     return null;
 }
 
-fn findAtomInSection(self: Object, addr: u64, n_sect: u8) ?Atom.Index {
+fn findAtomInSection(self: Object, addr: u64, n_sect: u8) Atom.Index {
     const tracy = trace(@src());
     defer tracy.end();
     const slice = self.sections.slice();
@@ -682,22 +682,15 @@ fn findAtomInSection(self: Object, addr: u64, n_sect: u8) ?Atom.Index {
         if (sub_addr == addr or (sub_addr < addr and addr < sub_addr + sub_size)) return sub.atom;
     }
 
-    return null;
+    return subsections.items[subsections.items.len - 1].atom;
 }
 
-fn linkNlistToAtom(self: *Object, macho_file: *MachO) !void {
+fn linkNlistToAtom(self: *Object, _: *MachO) !void {
     const tracy = trace(@src());
     defer tracy.end();
     for (self.symtab.items(.nlist), self.symtab.items(.atom)) |nlist, *atom| {
         if (!nlist.stab() and nlist.sect()) {
-            if (self.findAtomInSection(nlist.n_value, nlist.n_sect - 1)) |atom_index| {
-                atom.* = atom_index;
-            } else {
-                try macho_file.reportParseError2(self.index, "symbol {s} not attached to any (sub)section", .{
-                    self.getString(nlist.n_strx),
-                });
-                return error.MalformedObject;
-            }
+            atom.* = self.findAtomInSection(nlist.n_value, nlist.n_sect - 1);
         }
     }
 }
@@ -2339,12 +2332,7 @@ const x86_64 = struct {
                     @as(i64, @intCast(sect.addr)) + rel.r_address + addend + 4
                 else
                     addend;
-                const target = self.findAtomInSection(@intCast(taddr), @intCast(nsect)) orelse {
-                    try macho_file.reportParseError2(self.index, "{s},{s}: 0x{x}: bad relocation", .{
-                        sect.segName(), sect.sectName(), rel.r_address,
-                    });
-                    return error.MalformedObject;
-                };
+                const target = self.findAtomInSection(@intCast(taddr), @intCast(nsect));
                 addend = taddr - @as(i64, @intCast(macho_file.getAtom(target).?.getInputAddress(macho_file)));
                 break :blk target;
             } else self.symbols.items[rel.r_symbolnum];
@@ -2526,12 +2514,7 @@ const aarch64 = struct {
                     @as(i64, @intCast(sect.addr)) + rel.r_address + addend
                 else
                     addend;
-                const target = self.findAtomInSection(@intCast(taddr), @intCast(nsect)) orelse {
-                    try macho_file.reportParseError2(self.index, "{s},{s}: 0x{x}: bad relocation", .{
-                        sect.segName(), sect.sectName(), rel.r_address,
-                    });
-                    return error.MalformedObject;
-                };
+                const target = self.findAtomInSection(@intCast(taddr), @intCast(nsect));
                 addend = taddr - @as(i64, @intCast(macho_file.getAtom(target).?.getInputAddress(macho_file)));
                 break :blk target;
             } else self.symbols.items[rel.r_symbolnum];

[kubkon]

Apologies for the wait, the fix incoming in #21680. Instead of reverting the commit mentioned in the conversation above (which I believe is ultimately correct), we now create a dummy subsection at address of sect.addr + sect.size of size 0. This way, when a compiler such as Go emits a symbol pointing at sect.addr + sect.size (which technically lies outside of the section's end boundary) we can still link it to such a subsection.