Yeah, I looked at that when the story was posted last week, but:
$ CGO_ENABLED=1 GOOS=linux GOARCH=arm CC="zig cc -target arm-linux-gnu" go build ./test.go
# runtime/cgo
Invalid argument: -E
See `zig --help` for detailed usage information
cgo assumes some specific gcc/clang flags; something like tcc won’t work either. I didn’t look at it beyond this; it’s in the “I may work on this in the future, time and enthusiasm permitting”-category :-)
What was the “but” here? This looks like it should work.
Although I would recommend instead -target arm-linux-musleabihf. And make sure you’re using a latest master branch tarball or source build of zig. 0.6.0 is scheduled to be released on Monday.
It looks like the tool is calling zig -E ... rather than zig cc -E .... This is problematic not only because of namespacing the command but also since the -target option affects what defines are present. One might make the argument that the go tooling here has a bug.
Looks like this use case might require a wrapper script workaround, e.g.
#!/bin/sh
zig cc -target arm-linux-musleabihf $@
cgo assumes some specific gcc/clang flags
I also want to point out that this supports exactly clang’s flag set. The update script generates this based on clang’s own command line options data.
Ah yeah, that works; thanks. Like I said, I hadn’t investigated at all yet (I hadn’t even read the zig cc -help, speaking of which, -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang is probably my new favourite flag).
The wrong placement of the flags is probably something that can be fixed in Go; I’ve added a note to investigate the current logic a bit and report that on the Go tracker.
The compiler runs correct now, but run in to a few new errors which also seem to be on Go’s side of things. I’ll investigate next week or so and report back if there’s anything to fix or document on Zig’s end. Thanks!
Yeah, that feature is still being actively worked on (moving fast). Might be worth waiting until after zig 0.6 is released (I think target date is april 13 or so?) before you try again.
Maybe give
CC=“zig cc”a try?https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html
Yeah, I looked at that when the story was posted last week, but:
cgo assumes some specific gcc/clang flags; something like
tccwon’t work either. I didn’t look at it beyond this; it’s in the “I may work on this in the future, time and enthusiasm permitting”-category :-)What was the “but” here? This looks like it should work.
Although I would recommend instead
-target arm-linux-musleabihf. And make sure you’re using a latest master branch tarball or source build of zig. 0.6.0 is scheduled to be released on Monday.Oops, forgot to paste the error message >_<
It’s used to get a list of
#defines(gcc -E -dM -xc -).It looks like the tool is calling
zig -E ...rather thanzig cc -E .... This is problematic not only because of namespacing the command but also since the-targetoption affects what defines are present. One might make the argument that the go tooling here has a bug.Looks like this use case might require a wrapper script workaround, e.g.
I also want to point out that this supports exactly clang’s flag set. The update script generates this based on clang’s own command line options data.
Ah yeah, that works; thanks. Like I said, I hadn’t investigated at all yet (I hadn’t even read the
zig cc -help, speaking of which,-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clangis probably my new favourite flag).The wrong placement of the flags is probably something that can be fixed in Go; I’ve added a note to investigate the current logic a bit and report that on the Go tracker.
The compiler runs correct now, but run in to a few new errors which also seem to be on Go’s side of things. I’ll investigate next week or so and report back if there’s anything to fix or document on Zig’s end. Thanks!
-E isn’t a gcc or clang flag – it’s mandated by posix. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html
Ya, I just made the wrong assumption; I hadn’t checked in much detail 😅 And also didn’t expect Andrew to follow up here!
Yeah, that feature is still being actively worked on (moving fast). Might be worth waiting until after zig 0.6 is released (I think target date is april 13 or so?) before you try again.
Great article, thank you. Honestly did not realise these common packages needed dynamic linking. High info density read for me.