"Main.p_o.tmp: No such file or directory" while calling `ar` on `Main.p_o.tmp`

[Kleidukos]

The ar step fails with the following message in the ghcup-metadata pipeline:

*** systool:ar:
*** Ar:
"D:\a\_temp\foobarbaz\ghcup\ghc\9.6.3\lib\../mingw/bin/llvm-ar.exe" "qcL" "C:\\cabal\\script-builds\\%xfEvOiFMnTvjFvrlRdQhPuWQl\\build\\x86_64-windows\\ghc-9.6.3\\fake-package-0\\x\\script-main.hs\\build\\script-main.hs\\script-main.hs-tmp\Main.p_o.tmp" "C:\Users\RUNNER~1\AppData\Local\Temp\ghc3216_0\ghc_5.o" "C:\Users\RUNNER~1\AppData\Local\Temp\ghc3216_0\ghc_3.p_o"
D:/a/_temp/foobarbaz/ghcup/ghc/9.6.3/lib/../mingw/bin/llvm-ar.exe: error: C:\\cabal\\script-builds\\%xfEvOiFMnTvjFvrlRdQhPuWQl\\build\\x86_64-windows\\ghc-9.6.3\\fake-package-0\\x\\script-main.hs\\build\\script-main.hs\\script-main.hs-tmp\Main.p_o.tmp: No such file or directory

<no location info>: error:
    `llvm-ar.exe' failed in phase `Ar'. (Exit code: 1)

First encountered in haskell/ghcup-metadata#127

[mpickering]

The job where this fails is:
https://github.com/haskell/ghcup-metadata/actions/runs/6369779959/job/17290326630#step:3:15214

and the command seems to be :

cabal --verbose=0 run --enable-profiling ./main.hs -- +RTS -s

[gbaz]

The call (with arguments one to a line) is as follows

"D:\a\_temp\foobarbaz\ghcup\ghc\9.6.3\lib\../mingw/bin/llvm-ar.exe"
"qcL"
"C:\\cabal\\script-builds\\%xfEvOiFMnTvjFvrlRdQhPuWQl\\build\\x86_64-windows\\ghc-9.6.3\\fake-package-0\\x\\script-main.hs\\build\\script-main.hs\\script-main.hs-tmp\Main.p_o.tmp"
"C:\Users\RUNNER~1\AppData\Local\Temp\ghc3216_0\ghc_5.o"
"C:\Users\RUNNER~1\AppData\Local\Temp\ghc3216_0\ghc_3.p_o"

Note that the third argument has double rather than single backslashes (save the last component of the path). But all the other arguments only have single slashes -- both forward and back. Is this an escaping issue?

[ulysses4ever]

#9452 tries to reproduce it in the CI by adding a test

[jasagredo]

I think I found why this is failing. If I try to reproduce the same steps on my machine it doesn't fail, however if I introduce a % in the path then it fails with the same error.

I don't understand why cabal would produce a directory starting on % (in the error reported: C:\\cabal\\script-builds\\%xfEvOiFMnTvjFvrlRdQhPuWQl) but that seems to be the cause. I introduced the % by means of --builddir:

$ cabal run --enable-profiling Main.hs --verbose --ghc-options=-v --builddir "%123"
...
*** systool:ar:
*** Ar:
"C:\ghcup\ghc\9.6.3\lib\../mingw/bin/llvm-ar.exe" "qcL" "C:\\cabal\\script-builds\\d99686da9fae8161c6c95b8e44df81d5db8b92f51986dd9b56889e1b28121ecf\\%123\\build\\x86_64-windows\\ghc-9.6.3\\fake-package-0\\x\\cabal-script-Main.hs\\build\\cabal-script-Main.hs\\cabal-script-Main.hs-tmp\Main.p_o.tmp" "C:\msys64\tmp\ghc22672_0\ghc_5.o" "C:\msys64\tmp\ghc22672_0\ghc_3.p_o"
C:/ghcup/ghc/9.6.3/lib/../mingw/bin/llvm-ar.exe: error: C:\\cabal\\script-builds\\d99686da9fae8161c6c95b8e44df81d5db8b92f51986dd9b56889e1b28121ecf\\%123\\build\\x86_64-windows\\ghc-9.6.3\\fake-package-0\\x\\cabal-script-Main.hs\\build\\cabal-script-Main.hs\\cabal-script-Main.hs-tmp\Main.p_o.tmp: No such file or directory

<no location info>: error:
    `llvm-ar.exe' failed in phase `Ar'. (Exit code: 1)

However the file is there:

$ file /c/cabal/script-builds/d99686da9fae8161c6c95b8e44df81d5db8b92f51986dd9b56889e1b28121ecf/%123/build/x86_64-windows/ghc-9.6.3/fa
ke-package-0/x/cabal-script-Main.hs/build/cabal-script-Main.hs/cabal-script-Main.hs-tmp/Main.p_o
/c/cabal/script-builds/d99686da9fae8161c6c95b8e44df81d5db8b92f51986dd9b56889e1b28121ecf/%123/build/x86_64-windows/ghc-9.6.3/fake-package-0/x/cabal-script-Main.hs/build/cabal-script-Main.hs/cabal-script-Main.hs-tmp/Main.p_o: Intel amd64 COFF object file, not stripped, 5 sections, symbol offset=0xad7, 67 symbols, 1st section name ".text"

It seems llvm-ar.exe can't deal with % on the filepaths.

[ffaf1]

Maybe it could be this?

cabal/cabal-install/src/Distribution/Client/ScriptUtils.hs

Lines 221 to 235 in a134b26

	-- | Get the hash of a script's absolute path)
	--
	-- Two hashes will be the same as long as the absolute paths
	-- are the same.
	getScriptHash :: FilePath -> IO String
	getScriptHash script =
	-- Base64 is shorter than Base16, which helps avoid long path issues on windows
	-- but it can contain /'s which aren't valid in file paths so replace them with
	-- %'s. 26 chars / 130 bits is enough to practically avoid collisions.
	map (\c -> if c == '/' then '%' else c)
	. take 26
	. showHashValueBase64
	. hashValue
	. fromString
	<$> canonicalizePath script

a482a63 #8898

[gbaz]

great sleuthing both, and i bet that's the issue! we need to not only replace / with something else, but also % and whatever else might be invalid in a filepath too...