Consider paring down the set of output modes

[blackgnezdo]

TAB0 & TAB3 do not exist on OpenBSD

I'm using OpenBSD 7.2 & ghc 9.2.4.

compiling /home/greg/s/ghc/libraries/unix/dist-newstyle/build/x86_64-openbsd/ghc-9.2.4/unix-2.8.0.0/build/System/Posix/Terminal/Common_hsc_make.c failed (exit code 1)
rsp file was: "/home/greg/s/ghc/libraries/unix/dist-newstyle/build/x86_64-openbsd/ghc-9.2.4/unix-2.8.0.0/build/System/Posix/Terminal/hsc2hscall87316-0.rsp"
command was: /usr/bin/cc -c /home/greg/s/ghc/libraries/unix/dist-newstyle/build/x86_64-openbsd/ghc-9.2.4/unix-2.8.0.0/build/System/Posix/Terminal/Common_hsc_make.c -o /home/greg/s/ghc/libraries/unix/dist-newstyle/build/x86_64-openbsd/ghc-9.2.4/unix-2.8.0.0/build/System/Posix/Terminal/Common_hsc_make.o --target=x86_64-unknown-openbsd --target=x86_64-unknown-openbsd --target=x86_64-unknown-openbsd -fuse-ld=lld -Wl,-z,wxneeded -D__GLASGOW_HASKELL__=902 -Dopenbsd_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Dopenbsd_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Iinclude -I/home/greg/s/ghc/libraries/unix/dist-newstyle/build/x86_64-openbsd/ghc-9.2.4/unix-2.8.0.0/build/include -I/home/greg/s/ghc/libraries/unix/dist-newstyle/build/x86_64-openbsd/ghc-9.2.4/unix-2.8.0.0/build/autogen -I/home/greg/s/ghc/libraries/unix/dist-newstyle/build/x86_64-openbsd/ghc-9.2.4/unix-2.8.0.0/build/global-autogen -include /home/greg/s/ghc/libraries/unix/dist-newstyle/build/x86_64-openbsd/ghc-9.2.4/unix-2.8.0.0/build/autogen/cabal_macros.h -I/usr/local/lib/ghc/time-1.11.1.1/include -I/usr/local/lib/ghc/bytestring-0.11.3.1/include -I/usr/local/include -I/usr/local/lib/ghc/base-4.16.3.0/include -I/usr/local/include -I/usr/local/lib/ghc/ghc-bignum-1.2/include -I/usr/local/lib/ghc/include -I/usr/local/include -I/usr/local/lib/ghc/include/
error: cc: warning: -Wl,-z,wxneeded: 'linker' input unused [-Wunused-command-line-argument]
cc: warning: argument unused during compilation: '-fuse-ld=lld' [-Wunused-command-line-argument]
Common.hsc:177:16: error: use of undeclared identifier 'TAB0'
    hsc_const (TAB0);
               ^
Common.hsc:177:16: error: use of undeclared identifier 'TAB0'
Common.hsc:177:16: error: use of undeclared identifier 'TAB0'
Common.hsc:178:16: error: use of undeclared identifier 'TAB3'
    hsc_const (TAB3);
               ^

Steps to reproduce

cabal v2-build --allow-newer fails with the messages above. The first broken commit is 8302af3.

Expected behaviour

Successful build.

Actual behaviour

Build failure.

Posix compliance

The constants above are listed in Section 11.2.3 Output Modes. I'd argue they have no useful semantics or value going forward considering Haskell world lived without them for all this time. Many other constants had to be removed from the previous iteration of the patch because their support was spotty enough. Turns out the current set is still not universally supported.

I'm happy to send a patch removing just the two offending entries, if that's a reasonable course going forward. I'm invested in keeping GHC working on OpenBSD and this will be a constant thorn in my side personally.

[Bodigrim]

Fundamentally we cannot commit to support OpenBSD unless someone conjures up a CI job (either here or at GHC GitLab). Any ideas?

[blackgnezdo]

That should be easy enough. I've been keeping a more "interesting" case of syzkaller going for some 4 years now on GCE. Trouble is: I don't know who can give the free CPU cycles...

[Bodigrim]

Precisely, the biggest problem is to find a capable runner or service.

Removing constructors is a breaking change implying a major version bump. We cannot really carry on discovering such issues five years after they were merged.

[blackgnezdo]

The reason I discovered is GHC updated its dependency 3 weeks ago. Up until that point, I presume, the August release of 2.8.0.0 was not widely enough exposed outside mainstream.

So, what's the way forward, can I offer a bunch of #ifdef to make this not be a problem for people who just want to build GHC?

[Bodigrim]

To make a way forward we need a working CI, otherwise OpenBSD could be broken by the very next PR, making your efforts fruitless.

[Bodigrim]

It seems Cirrus CI might have some support for OpenBSD / NetBSD, for instance, https://github.com/elves/elvish/blob/master/.cirrus.yml

[hasufell]

The constants above are listed in Section 11.2.3 Output Modes. I'd argue they have no useful semantics or value

I can't follow this argument. They are defined in posix and as such we should support it.

If OpenBSD doesn't, we can ifdef them out. Not sure if we'll need more utility functions for portability there.

However GHC doesn't support OpenBSD at the moment and they have just dropped FreeBSD support as well. I'm not sure how much sense any of this makes, when the compiler devs will basically not make any guarantees whatsoever.

Sure, we can make sure unix builds on OpenBSD, but that's really just a small part of the problem, no?