Hi @NixOS/darwin-maintainers, we could use some help! On staging-next we have an updated autoconf that forces packages to use C23 when supported by the compiler, even if it's not that compiler's default. In Nixpkgs, this affects only Clang, because gcc already defaulted to C23. Clang is the default C compiler on macOS, but not on Linux. This means that we have a lot of macOS-specific failures that need to be resolved.

How to help

Find a broken package

The Problematic dependencies section of the Nix Review Tools Report shows the packages failing on staging-next, sorted by how many dependents they have, which is a rough measure of how high priority they are to fix. Not all of these will be regressions caused by the autoconf update. To identify those, follow the link to the Hydra build log, and check if it has the right characteristics:

• Contains the following line in the build log: "checking for clang option to enable C23 features... -std=gnu23"
• Build ultimately fails with a compiler error that either refers to C standard versions, or is a parse error or similar that could plausibly be caused by a difference in language versions.
• Build fails with an error following a warning already present in previous Hydra builds

If somebody wanted to go through the failure list and make a checklist of affected packages, that would be very helpful. :)

Fix it!

Try these steps in order:

1. Has the package already been updated upstream to be C23-compliant?
   • Try updating to the latest release
   • Try backporting a patch from the head of the development branch
2. Can we create a patch?
   • Submit to upstream and/or vendor it (see https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#fetching-patches)
3. Add "CFLAGS=-std=gnu17" to configureFlags (merge with existing value as needed)
   • If encountered error: invalid argument '-std=gnu17' not allowed with 'C++', add CXXFLAGS= to configureFlags.
4. Pin autoconf to autoconf269, and leave a comment here for discussion

For any changes, it's best to make them unconditional, because divergence between platforms makes testing all the different configurations harder. If you do need to make them conditional, the correct check in most cases will be stdenv.cc.isClang rather than stdenv.hostPlatform.isDarwin. If you need such a check to avoid lots of Linux rebuilds that would force the change to go to staging rather than staging-next, it's ideal to clean it up to be unconditional on staging later once the change propagates there.

Once you've fixed the package, open a Nixpkgs PR targeting staging-next, including the URL of this issue in your PR body. Do not include "closes" or "fixes" before the URL on a PR that only fixes it for individual package(s).

FAQ

Why not set the C standard upstream?

autoconf unfortunately does not provide a portable way to do this. Internally it has a list of which arguments to pass to different compilers to set the C standard, but there's no public API for these checks. Hardcoding : ${CFLAGS=-std=c17} would not be compatible with e.g. MSVC, which upstream might well care about even though we rarely do in Nixpkgs. It would be possible to do upstream for packages that only care about GCC-like compilers, including Clang, though.

Why gnu17 and not c17?

gnu17 is the Clang default, so that's what would have been used for these packages before the autoconf default changed.

Can I help from operating systems other than macOS?

Possibly! It depends on the package. Try building the package with LLVM on your OS, and see if you can reproduce the same build failure Hydra encountered on macOS. On Linux, you can do this by building the affected package from the pkgsLLVM package set. You might well encounter other failures specific to this setup before you actually get to the autoconf-related issue, though.

Why suggest CFLAGS in configureFlags, rather than NIX_CFLAGS_COMPILE?

In my opinion, it's better to avoid going behind the back of the build system with NIX_CFLAGS_COMPILE — they can be smarter if they actually know what the compiler is doing. I don't expect there's a situation in which CFLAGS wouldn't work but NIX_CFLAGS_COMPILE would, but if there is, go ahead with it. (I'd be interested to hear about it.)