@bgamari makes sense, but CI fails unfortunately.

@bgamari would not it suffice for GHC development purposes to remove config.sub only? This one is the only one, which is shown dirty after GHC build.

@bgamari marking as draft until CI issue is resolved.

Any news here?

I have rebased this and reworked the patch to only drop config.sub.

@bgamari @hasufell any ideas about CI failure on CentOS?

[ Info  ] Unpacking: ghc-9.4.7-x86_64-centos7-linux.tar.xz to /github/home/.ghcup/tmp/ghcup-9de163478a382955
[ Info  ] Installing GHC (this may take a while)
[ Error ] [./configure",
[ ...   ]                              "--prefix=/github/home/.ghcup/ghc/9.4.7"] failed with exit code 1.
[ Error ] Also check the logs in /github/home/.ghcup/logs
"ghcup --metadata-fetching-mode=Strict --cache install ghc recommended" failed!
Error: Process completed with exit code 2.

Very strange; unfortunately I have no idea. I have tried to reproduce this in a centos:7 Docker container but installation succeeded.

OK, CentOS and i386 failures are unrelated (see #300).

@bgamari this leaves us blocked on ARM jobs like https://github.com/haskell/unix/actions/runs/6395893930/job/17360539330?pr=283#step:7:137. Any ideas how to fix them?

configure: error: cannot run /bin/bash //github/workspace/config.sub
cabal: Failed to build unix-2.8.3.0. The failure occurred during the configure
step. The build process terminated with exit code 127

Oh dear, yes. The problem is that config.sub is needed on some platforms and needs to be populated using autoreconf. Typically, packages wanting to use Build-type: Configure will leave the generated autoconf files like config.sub out of the repository but then include them in the source distribution (as otherwise Cabal wouldn't be able to run the configure script). Under this scheme users who do build unix from the repository would need to run autoreconf before doing so. This is unfortunately but IMHO the best in a number of bad options.

@bgamari that's fine as long as you can fix the CI job. It seems to run autoreconf already?..

As much as I can figure out, the issue plagues runners with autoreconf-2.69. While autoreconf-2.71 happily generates configure / config.sub / config.guess from the scratch, autoreconf-2.69 generates configure only, which however unconditionally expects to find config.sub around:

  # Make sure we can run config.sub.
$SHELL "${ac_aux_dir}config.sub" sun4 >/dev/null 2>&1 ||
  as_fn_error $? "cannot run $SHELL ${ac_aux_dir}config.sub" "$LINENO" 5

I don't know what is the blessed way to resolve it, except migrating to autoreconf-2.71. I tried touch config.sub, but the next lines of configure actually expect it to produce meaningful output:

ac_cv_build=`$SHELL "${ac_aux_dir}config.sub" $ac_build_alias` ||
  as_fn_error $? "$SHELL ${ac_aux_dir}config.sub $ac_build_alias failed" "$LINENO" 5