0.12.1.0 fails to build on darwin aarch64 with GHC-8.10.7 about bytestring

[hasufell]

llvm13 is used via brew for 8.10.7

[clyring]

Ugh. It doesn't make sense to fail because of -Wundef inside of compiler-supplied headers. But there's no obvious convenient way to say "just -Werror=undef for the code in this package."

Thanks for reporting. Does adding --ghc-options="-optP -Wno-error=undef -optc -Wno-error=undef" work around the problem?

[Bodigrim]

I think the immediate action is to make a revision for bytestring-0.12.1.0 prohibiting any builds with GHC < 9. While blunt, I don't believe it to hurt anyone and should resolve @hasufell's immediate issue (which is, I imagine, Cabal keen to use the latest and greatest releases).

[clyring]

I was thinking rather of making a revision that just removes the -Werror=undef bits. Or is that not allowed? I'm not too clear on the extent of what Hackage revisions can and can't do.

[Bodigrim]

No, you cannot change build flags, only dependency versions: https://hackage.haskell.org/package/bytestring-0.12.1.0/bytestring.cabal/edit

[clyring]

I see. It also looks possible to use our existing if (arch(aarch64)) block to only add the old-ghc-blocking base >= 4.15 constraint on that platform, which is a fair amount less blunt if it works. (But without having traced the bad included #if on a failing platform it's not a priori obvious exactly what the right condition is.)

[Bodigrim]

IIRC my experiments at https://github.com/haskell/bytestring/actions/runs/7791721116/job/21289850270, nothing before GHC 9.4 worked reliably on macOS aarch64.

[clyring]

It looks like this gets worked around on GHC's end since !10750 which appears starting with 9.4.6, 9.6.3, and 9.8.1.

[clyring]

Conveniently, both of the minor releases 9.4.6 and 9.6.3 bumped the base version. I've pushed a revision that checks for the corresponding base versions on aarch64. (It occurs to me now that a user could probably still get into trouble with -fpure-haskell on ghc-9.6.2. I'm inclined to not worry about that unless someone complains.)

[hasufell]

The defaults should be the most portable imo, not the most performant.

[clyring]

I'm not sure what you're getting at.

[hasufell]

I misread the flags, I was under the impression this is related to the standard C routines.

Then I'd suggest to make a new point release that removes Werror and manually enables it for CI.

[clyring]

I agree about removing -Werror=undef from the package configuration in the future to reduce the likelihood of this sort of problem re-occurring.

If there was an easy way to make -Werror=undef apply to only our CPP (and not stupid upstream CPP like this) I'd really like to keep it on, though, because if it fires in our code that is nearly 100% likely to be a bug. (And the flag has saved me a lot of debug time while refactoring already...)