Building GHC 9.4.5 from source fails because of deprecated Hadrian flag

[isomorpheme]

General summary/comments (optional)

Stack calls Hadrian with -c here, but that option has been deprecated (which in this case means not much less than "removed") for a while: https://gitlab.haskell.org/ghc/ghc/-/issues/20167

Building GHC currently requires running ./boot && ./configure before calling Hadrian.

Steps to reproduce

1. Create a Stack project on LTS 21.0 with stack new.
2. stack build --compiler=ghc-git-a213d3676550a0e4d542172de539c0cfa2662431-quickest (that commit is the one tagged as ghc-9.4.5-release in the GHC repo).

Expected

GHC built from source successfully.

Actual

Stack builds Hadrian successfully, but then:

shake: hadrian --configure has been deprecated (see #20167). Please run ./boot; ./configure manually

Usage: hadrian [options] [target] ...

Standard options:
# ... snip ...
Extra options:
  -c, --configure             Deprecated: Run the boot and configure scripts.
# ... snip ...

Received ExitFailure 1 when running
Raw command: /tmp/with-repo1432778/cloned/hadrian/build-stack -c -j8 --flavour=quickest binary-dist
Run from: /tmp/with-repo1432778/cloned

Stack version

In my project's nix-shell:

stack --version
2.9.1 x86_64 hpack-0.35.2

But I've also tried with Stack installed from GHCup:

stack --version
Version 2.11.1, Git revision c1167a6abc3f4978ccded5ba0246a57387da0e2f x86_64 hpack-0.35.2

Method of installation

• Via GHCup
• Other: Via Nix

Platform

Linux x86_64, Ubuntu.

[hasufell]

We could support compiling from source via installation hooks (GHCup):

• https://docs.haskellstack.org/en/stable/yaml_configuration/#ghc-installation-customisation
• https://github.com/haskell/ghcup-hs/blob/1f220cd4883f24848b4a4bc10171494718894e55/scripts/hooks/stack/ghc-install.sh#L16

We would just need some convention in the shell hook, so that already compiled GHCs are detected properly. Otherwise you end up compiling for every invocation.

Building via GHCup should work.

[mpilgrem]

So, Stack.Setup.buildGhcFromSource has:

proc (toFilePath hadrianPath) hadrianArgs runProcess_

where:

let hadrianArgs = fmap T.unpack
      [ "-c"                    -- run ./boot and ./configure
      , "-j" <> tshow threads   -- parallel build
      , "--flavour=" <> flavour -- selected flavour
      , "binary-dist"
      ]

I understand from https://gitlab.haskell.org/ghc/ghc/-/blob/master/hadrian/README.md, that Stack should command:

boot
configure # On Windows, configure --enable-tarballs-autodownload

and then run the Hadrian script (with the remainder of the arguments). I'll raise a pull request, accordingly.

[mpilgrem]

This is proving to be a little more complex than I thought:

• the GHC repository's configure script says that it requires GHC >= 9.2, but ...
• the GHC repository's hadrian/stack.yaml specifies resolver lts-19.8 (GHC 9.0.2)!
• the GHC repository's configure script says that it also requires certain versions of happy and alex executables to already be on the PATH.

[mpilgrem]

I have something that appears to sort-of-work, once I had installed various MSYS2 and python packages that do not come with the Stack-supplied MSYS2 but seem to be pre-requsites, but stack build --compiler=ghc-git-a213d3676550a0e4d542172de539c0cfa2662431-quickest still fails with:

# ghc-pkg (for binary-dist-dir)
| Run Sphinx LatexMode: utils/haddock/doc => C:/Users/mikep/AppData/Local/Temp/extra-dir-588155584636
| Create directory _build/stage1/haddock-timing-files
| Run Sphinx HtmlMode: utils/haddock/doc => _build/doc/html/Haddock
| Run Haddock BuildPackage: libraries/ghc-prim/GHC/CString.hs (and 12 more) => _build/doc/html/libraries/ghc-prim-0.9.0/ghc-prim.haddock
| Run Sphinx ManMode: docs/users_guide => C:/Users/mikep/AppData/Local/Temp/extra-dir-588155584638
| Run Sphinx LatexMode: docs/users_guide => C:/Users/mikep/AppData/Local/Temp/extra-dir-588155584637
| Run Sphinx HtmlMode: docs/users_guide => _build/doc/html/users_guide
Command line: C:/Users/mikep/AppData/Local/Programs/stack/x86_64-windows/msys2-20210604/mingw64/bin/sphinx-build.exe -b html -d _build/doc/html/users_guide/.doctrees-html -n -w _build/doc/html/users_guide/.log docs/users_guide _build/doc/html/users_guide
===> Command failed with error code: 2

Exception occurred:
  File "C:/Users/mikep/AppData/Local/Programs/stack/x86_64-windows/msys2-20210604/mingw64/lib/python3.9/site-packages/sphinx/ext/extlinks.py", line 103, in role
    title = caption % part
TypeError: not all arguments converted during string formatting
The full traceback has been saved in C:/Users/mikep/AppData/Local/Temp/sphinx-err-munph_t4.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
Running Sphinx v7.0.1
building [mo]: targets for 0 po files that are out of date
writing output...
building [html]: targets for 159 source files that are out of date
updating environment: [new config] 159 added, 0 changed, 0 removed
Command faileds... [  0%] 9.4.1-notes
Build failed.

Received ExitFailure 1 when running
Raw command: "C:\\Users\\mikep\\AppData\\Local\\Temp\\with-repo17420\\cloned\\hadrian\\build-stack.bat" -j8 --flavour=quickest binary-dist
Run from: C:\Users\mikep\AppData\Local\Temp\with-repo17420\cloned

Sphinx v7.0.1 is the latest non-development version, according to this.

The bit of python code that is being objected to is this:

def make_link_role(name: str, base_url: str, caption: str) -> RoleFunction:
    # Check whether we have base_url and caption strings have an '%s' for
    # expansion.  If not, fall back the the old behaviour and use the string as
    # a prefix.
    # Remark: It is an implementation detail that we use Pythons %-formatting.
    # So far we only expose ``%s`` and require quoting of ``%`` using ``%%``.
    def role(typ: str, rawtext: str, text: str, lineno: int,
             inliner: Inliner, options: dict = {}, content: list[str] = [],
             ) -> tuple[list[Node], list[system_message]]:
        text = utils.unescape(text)
        has_explicit_title, title, part = split_explicit_title(text)
        full_url = base_url % part
        if not has_explicit_title:
            if caption is None:
                title = full_url
            else:
                title = caption % part
        pnode = nodes.reference(title, title, internal=False, refuri=full_url)
        return [pnode], []
    return role

EDIT: The error is discussed here: sphinx-doc/sphinx#11094. EDIT 2: This is a known bug in GHC 9.4.5: https://gitlab.haskell.org/ghc/ghc/-/issues/23286.

[mpilgrem]

Outside of Stack, applying the steps manually, I had no better luck with the head of the master branch of the GHC repository (commit cec903899234bf9e25ea404477ba846ac1e963bb). It failed with:

# ghc-pkg (for binary-dist-dir)
| Successfully generated libraries/prologue.txt from its template
| Successfully generated docs/index.html from its template
Error, file does not exist and no rule available:
  C:/Users/mike/AppData/Local/Programs/stack/x86_64-windows/msys2-20230526/usr/bin/sphinx-build.exe
Build failed.

It seems to be looking for a sphinx-build.exe file, when:

> stack exec -- where.exe sphinx-build
C:\Users\mike\AppData\Local\Programs\stack\x86_64-windows\msys2-20230526\usr\bin\sphinx-build

sphinx-build is a script, not an *.exe.

EDIT: I solved the problem above by a re-install of the Stack-supplied MSYS2 and reinstalling the pre-requisite MSYS2 and python packages. I do not know what I did differently, but second time around I had an *.exe, not a script.

However, now hadrian fails, late on, with (reformatted):

# python3 (for docs)
Command line: C:/Users/mikep/AppData/Local/Programs/stack/x86_64-windows/msys2-20230526/usr/bin/python3.exe 
C:/Users/mikep/AppData/Local/Temp/with-repo31540/cloned\docs/users_guide/compare-flags.py 
--doc-flags _build/doc/html/users_guide/ghc-flags.txt 
--ghc C:/Users/mikep/AppData/Local/Temp/with-repo31540/cloned\_build/stage1/bin/ghc.exe
===> Command failed with error code: 2
/usr/bin/python3.exe: can't open file '/c/Users/mikep/AppData/Local/Temp/with-repo31540/cloned/C:/Users/mikep/AppData/Local/Temp/with-repo31540/cloned\\docs/users_guide/compare-flags.py': [Errno 2] No such file or directory
Command failed
Build failed.
Run from: C:\Users\mikep\AppData\Local\Temp\with-repo31540\cloned

It looks like something is appending an absolute path to another absolute path.

Notes to self:

Rules.Documentation.checkUserGuideFlags has:

-- | Check that all GHC flags are documented in the users guide.
checkUserGuideFlags :: FilePath -> Action ()
checkUserGuideFlags documentedFlagList = do
    scriptPath <- (</> "docs/users_guide/compare-flags.py") <$> topDirectory
    ghc <- programPath (vanillaContext Stage1 ghc)
    need [ghc]
    ghcPath <- (</>) <$> topDirectory <*> pure ghc
    runBuilder Python
      [ scriptPath
      , "--doc-flags", documentedFlagList
      , "--ghc", ghcPath
      ] [documentedFlagList] []

EDIT: the problem appears to be that python3.exe converts the path C:/Users/mikep/AppData/Local/Temp/with-repo31540/cloned\docs/users_guide/compare-flags.py into /c/Users/mikep/AppData/Local/Temp/with-repo31540/cloned/C:/Users/mikep/AppData/Local/Temp/with-repo31540/cloned\\docs/users_guide/compare-flags.py or, more generally, into <cwd>/C:/Users/mikep/AppData/Local/Temp/with-repo31540/cloned\\docs/users_guide/compare-flags.py, where <cwd> is the absolute current working directory in MSYS2 'Unix' format.

EDIT2: This appears to be a known issue with python from some MSYS2 repos: msys2/MSYS2-packages#2628.

[mpilgrem]

@isomorpheme, I have posted my sort-of-works Stack solution as pull request #6181, but to test it I need to find a commit in the GHC repository where hadrian works 'locally'.

[mpilgrem]

Very close: the build of GHC now completes but there is then something wrong with the contents of the archive file that has been created (extracts only):

# tar (for binary-dist)
Build completed in 8h53m

Already downloaded 7z.dll.
Already downloaded 7z.exe.
Decompressing ghc-9.9.20230630-x86_64-unknown-mingw32.tar.xz...

7-Zip 22.01 (x64) : Copyright (c) 1999-2022 Igor Pavlov : 2022-07-15

Scanning the drive for archives:
1 file, 287907740 bytes (275 MiB)

Extracting archive: C:\Users\mikep\AppData\Local\Temp\with-repo14036\cloned\_build\bindist\ghc-9.9.20230630-x86_64-unknown-mingw32.tar.xz
--
Path = C:\Users\mikep\AppData\Local\Temp\with-repo14036\cloned\_build\bindist\ghc-9.9.20230630-x86_64-unknown-mingw32.tar.xz
Type = xz
Physical Size = 287907740
Method = LZMA2:23 CRC64
Streams = 1
Blocks = 1

Everything is Ok

Size:       2342543360
Compressed: 287907740
Extracting ghc-9.9.20230630-x86_64-unknown-mingw32.tar...
Extract
Extracted 15 files
Cannot open output file : The filename, directory name, or volume label syntax is incorrect. : C:\Users\mikep\AppData\Local\Programs\stack\x86_64-windows\ghc-git-cec903899234bf9e25ea404477ba846ac1e963bb-quickest-tmp-30c607da0dcd07fc\\ghc-9.9.20230630-x86_64-unknown-mingw32\doc\html\libraries\base-4.18.0.0-inplace\GHC-Event-Windows-ManagedThreadPool.html
ERROR: Cannot open output file : The filename, directory name, or volume label syntax is incorrect. : C:\Users\mikep\AppData\Local\Programs\stack\x86_64-windows\ghc-git-cec903899234bf9e25ea404477ba846ac1e963bb-quickest-tmp-30c607da0dcd07fc\\ghc-9.9.20230630-x86_64-unknown-mingw32\doc\html\libraries\base-4.18.0.0-inplace\src\GHC.Event.Windows.ManagedThreadPool.html
...
ERROR: Cannot open output file : The filename, directory name, or volume label syntax is incorrect. : C:\Users\mikep\AppData\Local\Programs\stack\x86_64-windows\ghc-git-cec903899234bf9e25ea404477ba846ac1e963bb-quickest-tmp-30c607da0dcd07fc\\ghc-9.9.20230630-x86_64-unknown-mingw32\mingw\lib\clang\14.0.6\lib\windows\libclang_rt.asan_dynamic_runtime_thunk-x86_64.a
Extracted total of 21 files from ghc-9.9.20230630-x86_64-unknown-mingw32.tar

Error: [S-2905]
       Problem while decompressing
       C:\Users\mikep\AppData\Local\Programs\stack\x86_64-windows\ghc-git-cec903899234bf9e25ea404477ba846ac1e963bb-quickest-tmp-30c607da0dcd07fc\ghc-9.9.20230630-x86_64-unknown-mingw32.tar.

From the error messages alone, the problem seems to be a double file path separator (\\) between C:\Users\mikep\AppData\Local\Programs\stack\x86_64-windows\ghc-git-cec903899234bf9e25ea404477ba846ac1e963bb-quickest-tmp-30c607da0dcd07fc and (for example) ghc-9.9.20230630-x86_64-unknown-mingw32\mingw\lib\clang\14.0.6\lib\windows\libclang_rt.asan_dynamic_runtime_thunk-x86_64.a.

EDIT: However, these file paths are longer than 260 characters. Could the underlying problem actually be Windows' default 260 character file path length limit? EDIT2: Yes! The problem disappears if the length of the temporary directory name is truncated.