cabal-testsuite fails early on with linker error on Windows since GHC 9.6

[ulysses4ever]

Describe the bug
Here's a failed run for example. The salient bit is:

C:\sr\ghc-9.6.1\network-3.1.2.8-47daa736ec70bcbdeddd189bd8a4e60d34db9fe7\lib\libHSnetwork-3.1.2.8-47daa736ec70bcbdeddd189bd8a4e60d34db9fe7.a: unknown symbol `__mingw_vsprintf'

To Reproduce
This needs to be investigated but generally speaking, our validate.sh -s lib-suite on Windows.

Expected behavior
No failure.

System information

• Operating system: Windows
• cabal, ghc: 3.8.1.0 and 9.6.1

Additional context

Sadly enough, we'll have to disable a big chunk of CI on Windows for GHC 9.6.1 if this is not fixed.

/cc @Mistuke @jneira

[mpilgrem]

Is this a Cabal library bug? I have just tried to build Stack (with Stack) on Windows 11 with the new snapshot for GHC 9.4.5 (Stackage Nightly nightly-2023-04-25) and it fails with a similar sort of message (again, complaining about 'unknown symbols') [EDIT GHC 9.4.4 works fine]:

pantry> ghc-9.4.5.exe:  | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\network-3.1.2.8-DIslA85FC627S0eMFb26Fp\libHSnetwork-3.1.2.8-DIslA85FC627S0eMFb26Fp.a: unknown symbol `__mingw_vsprintf'
pantry> ghc-9.4.5.exe:  | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\network-3.1.2.8-DIslA85FC627S0eMFb26Fp\libHSnetwork-3.1.2.8-DIslA85FC627S0eMFb26Fp.a: unknown symbol `getWSErrorDescr'
pantry> ghc-9.4.5.exe:  | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\network-3.1.2.8-DIslA85FC627S0eMFb26Fp\libHSnetwork-3.1.2.8-DIslA85FC627S0eMFb26Fp.a: unknown symbol `networkzm3zi1zi2zi8zmDIslA85FC627S0eMFb26Fp_NetworkziSocketziInternal_withSocketsInit_closure'
pantry> ghc-9.4.5.exe:  | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\network-3.1.2.8-DIslA85FC627S0eMFb26Fp\libHSnetwork-3.1.2.8-DIslA85FC627S0eMFb26Fp.a: unknown symbol `networkzm3zi1zi2zi8zmDIslA85FC627S0eMFb26Fp_NetworkziSocketziBuffer_zdwsendBuf_closure'
pantry> ghc-9.4.5.exe:  | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\tls-1.6.0-L7vOrX5PXtxCYn6XOlo0lf\libHStls-1.6.0-L7vOrX5PXtxCYn6XOlo0lf.a: unknown symbol `networkzm3zi1zi2zi8zmDIslA85FC627S0eMFb26Fp_NetworkziSocketziByteStringziIO_zdwrecv_closure'
pantry> ghc-9.4.5.exe:  | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\tls-1.6.0-L7vOrX5PXtxCYn6XOlo0lf\libHStls-1.6.0-L7vOrX5PXtxCYn6XOlo0lf.a: unknown symbol `tlszm1zi6zi0zmL7vOrX5PXtxCYn6XOlo0lf_NetworkziTLSziBackend_zdtcBackend_closure'
pantry> ghc-9.4.5.exe:  | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\connection-0.3.1-6Q8NoORXRD3cfhY8fQImM\libHSconnection-0.3.1-6Q8NoORXRD3cfhY8fQImM.a: unknown symbol `tlszm1zi6zi0zmL7vOrX5PXtxCYn6XOlo0lf_NetworkziTLSziContextziInternal_zdtcContext_closure'
pantry> ghc-9.4.5.exe:  | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\http-client-tls-0.3.6.1-1irORuvOSZS7lk0vW4RHCH\libHShttp-client-tls-0.3.6.1-1irORuvOSZS7lk0vW4RHCH.a: unknown symbol `connectionzm0zi3zi1zm6Q8NoORXRD3cfhY8fQImM_NetworkziConnectionziTypes_SockSettingsSimple_con_info'
pantry> ghc-9.4.5.exe:  | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\casa-client-0.0.1-CluYGfz85ea6VJMUkpqtF2\libHScasa-client-0.0.1-CluYGfz85ea6VJMUkpqtF2.a: unknown symbol `httpzmclientzmtlszm0zi3zi6zi1zm1irORuvOSZZS7lk0vW4RHCH_NetworkziHTTPziClientziTLS_globalManager_closure'
pantry> ghc-9.4.5.exe: ^^ Could not load 'casazmclientzm0zi0zi1zmCluYGfzz85ea6VJMUkpqtF2_CasaziClient_thParserCasaRepo_closure', dependency unresolved. See top entry above.
pantry>
pantry>
pantry> <no location info>: error:
pantry>
pantry> GHC.ByteCode.Linker.lookupCE
pantry> During interactive linking, GHCi couldn't find the following symbol:
pantry>   casazmclientzm0zi0zi1zmCluYGfzz85ea6VJMUkpqtF2_CasaziClient_thParserCasaRepo_closure
pantry> This may be due to you not asking GHCi to load extra object files,
pantry> archives or DLLs needed by your current session.  Restart GHCi, specifying
pantry> the missing library using the -L/path/to/object/dir and -lmissinglibname
pantry> flags, or simply by naming the relevant files on the GHCi command line.
pantry> Alternatively, this link failure might indicate a bug in GHCi.
pantry> If you suspect the latter, please report this as a GHC bug:
pantry>   https://www.haskell.org/ghc/reportabug
pantry>

I asked at the network repository (previously) and it was suggested there that the bug is not in network or GHC. By a process of elimination that suggests it might be Cabal (the library).

[gbaz]

I don't think Kazu's comment rules out ghc. I agree it seems unlikely to specifically be a network issue. It could well be a build-environment issue -- perhaps the mingw libraries shipped with ghc 9.6.1 are not in the same path, or perhaps the path needs further configuration (in the cabal.config file) to accurately locate those dirs, or perhaps all that is correct and the regression is cabal isn't handling those paths in the same way?

Note that if this is 9.6 specific it seems unlikely to be a cabal issue, since for ghc 9.4, the windows action (which succeeds, I believe) uses the same version of cabal. So if the choice of ghc version rather than the choice of cabal version triggers this, then something about ghc -- perhaps the distribution and not the compiler itself -- would be at issue.

A further differential diagnosis could come from seeing if this only occurs with chocolatey installs of ghc (as in the actions) or also from ghcup ones, or just "raw" ones from the official distribution from ghchq itself.

[mpilgrem]

If it is GHC, it is affecting the binary versions that are published via https://www.haskell.org/ghc/download.html and both the new GHC 9.4.5 and 9.6.1. I'll raise a GHC issue.