`cargo-zigbuild` fails to collect `zig cc` options when using `setup-zig`

[jlizen]

Context: awslabs/aws-lambda-rust-runtime#1006

cargo-lambda is a popular build tool that compiles AWS Rust lambdas with a mode that involves cargo-zigbuild. The typical way of using it in CI is via a workflow that starts with this action (example).

However, this recently started failing due to the error:

Failed to collect 'zig cc' options

We have root caused this error to result from missing the zig stdlib, various header files, etc, on $PATH: ref. The tarball includes those in ./lib/**, whereas the zig binary is at ./zig.

So, it seems that the $PATH additions from this action either are restricted only to the binary, or are not including these directories.

This is confusing to me, since my reading of the action code makes it look like we are in fact caching/exposing the full tarball contents, which should include /lib.

I poked around the action locally and couldn't figure out how to get it working. Opening this issue in case brighter minds know the path forward :)

[mlugg]

Looking at this, I don't believe there to be a bug in setup-zig.

The theory about the Zig lib/ directory being missing from the installation is definitely not correct. That would be a severe bug, which would prevent any Zig usage at all from working with this Action (since the lib/ directory is essential to every non-trivial zig subcommand). This Action does indeed extract the Zig archive in full, resulting in a correct installation.

It looks like this diagnosis originated from this comment. However, the author of that comment has incorrectly assumed that the error message implies the same problem in your case as in their case. This is incorrect. The "Failed to collect 'zig cc' options" error message seems to be a quite general error in cargo-zigbuild, which can indicate several issues. (By the way, I have experienced this specific user confidently misdiagnosing bugs in this repository with the help of an LLM; I'd recommend treating their reports with some level of skepticism.)

I did a little sleuthing through the cargo-zigbuild code to try and figure out what could be causing the error in question. This message comes from a Result.context(...) call:

https://github.com/rust-cross/cargo-zigbuild/blob/2451158177a9d0984b654cca8ffb7b5144e7a858/src/zig.rs#L635

I don't know any Rust, but my understanding from a little Googling of syntax and functions is that this is adding an extra piece of information to an existing error message, which that collect_zig_cc_options function will have returned probably through ? or bail!. It looks to me like every error return site in collect_zig_cc_options would probably have an existing message associated with the error telling you what actually went wrong (whether the zig cc -v command failed, or the output couldn't be parsed, etc). If I've understood all of that correctly, then it seems to me that whatever is forwarding the error from cargo-zigbuild is dropping some of the message -- information critical to tracking down this problem. My best guess at this stage is that this is a bug in cargo-zigbuild, but I don't think I can do anything else without further information.

I'm relatively sure that setup-zig isn't the problem here, so I'm going to close this issue for now. If you find more information and need any further help, drop another comment here and I'll do my best to help you out.

[jlizen]

Thanks a bunch for the initial sleuthing @mlugg ! No concerns about leaving this issue closed out. And understood re: mixed history of diagnosis from the author of the linked comment (though in this case the mistake of conflating the other issue with this action was my own :) ).

Though if I understand your point correctly, it sounds likely that the cargo-lambda issue is probably ongoing as well, if potentially originating from a cargo-zigbuild bug. Since, pinning it back in my workflow does address the issue, and this action does indeed provide the needed library directory. So the mentioned dockerfile fix seems orthogonal.

I'll start poking around cargo-zigbuild when I have a spare moment. Appreciate the pointers.

[mlugg]

Yes, I don't mean to suggest that the cargo-lambda issue is resolved. It seems to me that cargo-lambda/cargo-lambda#856 should be re-opened until the real underlying issue is tracked down. I imagine that'll be much easier once you can actually see the full error cargo-zigbuild is returning.