Cabal fails to set object format when joining objects on Windows

[bgamari]

Describe the bug
Due to limitations of the PE object format, it is in general necessary to pass --oformat=pe-bigobj-x86-64 to the linker when joining Haskell object files on Windows lest one encounter linker errors due to too many sections. This is particularly true when split-sections is enabled (as it produces significantly more sections than otherwise would be produced).

Currently Cabal fails to do this, resulting in GHC#20682.

To Reproduce
Steps to reproduce the behavior (on Windows)

$ git clone https://gitlab.haskell.org/bgamari/T20506-repro
$ cd T20506-repro
$ cabal build -v3

The build will fail with:

Environment: [("!;",";\\"),("ALLUSERSPROFILE","C:\\ProgramData"),("ANSICON","237x1000 (237x51)"),("ANSICON_DEF","7"),("APPDATA","C:\\Users\\ben\\AppData\\Roaming"),("COMMONPROGRAMFILES","C:\\Program Files\\Common Files"),("COMMONPROGRAMFILES(X86)","C:\\Program Files (x86)\\Common Files"),("COMMONPROGRAMW6432","C:\\Program Files\\Common Files"),("COMPUTERNAME","DESKTOP-7U5RJIJ"),("COMSPEC","C:\\WINDOWS\\system32\\cmd.exe"),("CONEMUANSI","ON"),("CONEMUBACKHWND","0x00010282"),("CONEMUBASEDIR","C:\\Program Files\\ConEmu\\ConEmu"),("CONEMUBASEDIRSHORT","C:\\PROGRA~1\\ConEmu\\ConEmu"),("CONEMUBUILD","210422"),("CONEMUCFGDIR","C:\\Users\\ben\\AppData\\Roaming"),("CONEMUDIR","C:\\Program Files\\ConEmu"),("CONEMUDRAWHWND","0x00010284"),("CONEMUDRIVE","C:"),("CONEMUHOOKS","Enabled"),("CONEMUHWND","0x0001020E"),("CONEMUPALETTE","<Cobalt2>"),("CONEMUPID","556"),("CONEMUSERVERPID","8388"),("CONEMUTASK","{Bash::Msys2-64}"),("CONEMUWORKDIR","C:\\Users\\ben"),("CONEMUWORKDRIVE","C:"),("CONFIG_SITE","C:/msys64/etc/config.site"),("DRIVERDATA","C:\\Windows\\System32\\Drivers\\DriverData"),("FPS_BROWSER_APP_PROFILE_STRING","Internet Explorer"),("FPS_BROWSER_USER_PROFILE_STRING","Default"),("HASKELL_DIST_DIR","dist"),("HOME","C:\\msys64\\home\\ben"),("HOMEDRIVE","C:"),("HOMEPATH","\\Users\\ben"),("HOSTNAME","DESKTOP-7U5RJIJ"),("INFOPATH","C:\\msys64\\usr\\local\\info;C:\\msys64\\usr\\share\\info;C:\\msys64\\usr\\info;C:\\msys64\\share\\info"),("LANG","en_US.UTF-8"),("LOCALAPPDATA","C:\\Users\\ben\\AppData\\Local"),("LOGONSERVER","\\\\DESKTOP-7U5RJIJ"),("MANPATH","C:\\msys64\\usr\\local\\man;C:\\msys64\\usr\\share\\man;C:\\msys64\\usr\\man;C:\\msys64\\share\\man"),("MSYSTEM","MSYS"),("MSYSTEM_CARCH","x86_64"),("MSYSTEM_CHOST","x86_64-pc-msys"),("MSYSTEM_PREFIX","C:/msys64/usr"),("NUMBER_OF_PROCESSORS","8"),("OLDPWD","C:/msys64/home/ben"),("ONEDRIVE","C:\\Users\\ben\\OneDrive"),("ONEDRIVECONSUMER","C:\\Users\\ben\\OneDrive"),("ORIGINAL_PATH","C:\\Windows\\System32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\"),("ORIGINAL_TEMP","C:/Users/ben/AppData/Local/Temp"),("ORIGINAL_TMP","C:/Users/ben/AppDaa/Local/Temp"),("OS","Windows_NT"),("PATH","C;C:\\Users\\ben\\AppData\\Roaming\\cabal\\bin;C:\\msys64\\usr\\local\\bin;C:\\msys64\\usr\\bin;C:\\msys64\\usr\\bin;C:\\msys64\\opt\\bin;C:\\Windows\\System32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\msys64\\usr\\bin\\site_perl;C:\\msys64\\usr\\bin\\vendor_perl;C:\\msys64\\usr\\bin\\core_perl;C:\\Users\\ben\\AppData\\Roaming\\cabal\\bin"),("PATHEXT",".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"),("PKG_CONFIG_PATH","C:\\msys64\\usr\\lib\\pkgconfig;C:\\msys64\\usr\\share\\pkgconfig;C:\\msys64\\lib\\pkgconfig"),("PRINTER","Microsoft Print to PDF"),("PROCESSOR_ARCHITECTURE","AMD64"),("PROCESSOR_IDENTIFIER","AMD64 Family 23 Model 1 Stepping 2, AuthenticAMD"),("PROCESSOR_LEVEL","23"),("PROCESSOR_REVISION","0102"),("PROGRAMDATA","C:\\ProgramData"),("PROGRAMFILES","C:\\Program Files"),("PROGRAMFILES(X86)","C:\\Program Files (x86)"),("PROGRAMW6432","C:\\Program Files"),("PS1","\\[\\e]0;\\w\\a\\]\\n\\[\\e[32m\\]\\u@\\h \\[\\e[35m\\]$MSYSTEM\\[\\e[0m\\] \\[\\e[33m\\]\\w\\[\\e[0m\\]\\n\\$ "),("PSMODULEPATH","C:\\Program Files\\WindowsPowerShell\\Modules;C:\\WINDOWS\\system32\\WindowsPowerShell\\v1.0\\Modules"),("PUBLIC","C:\\Users\\Public"),("PWD","C:/msys64/home/ben/tmp"),("SESSIONNAME","Console"),("SHELL","C:/msys64/usr/bin/bash"),("SHLVL","1"),("STACK_ROOT","C:\\sr"),("SYSTEMDRIVE","C:"),("SYSTEMROOT","C:\\WINDOWS"),("TEMP","C:\\Users\\ben\\AppData\\Local\\Temp"),("TERM","xterm-256color"),("TMP","C:\\Users\\ben\\AppData\\Local\\Temp"),("TMP_DATADIR","C:\\msys64\\home\\ben\\tmp\\."),("USER","ben"),("USERDOMAIN","DESKTOP-7U5RJIJ"),("USERDOMAIN_ROAMINGPROFILE","DESKTOP-7U5RJIJ"),("USERNAME","ben"),("USERPROFILE","C:\\Users\\ben"),("VK_SDK_PATH","C:\\VulkanSDK\\1.2.162.0"),("VULKAN_SDK","C:\\VulkanSDK\\1.2.162.0"),("WINDIR","C:\\WINDOWS"),("_","\\Users\\ben\\AppData\\Roaming/cabal/bin/cabal")]
"C:\msys64\home\ben\ghc-8.10.4\lib\../mingw/bin\ld.exe" "-x" "-r" "-o" "dist\build\HSOpenGLRaw-3.3.4.1-4f4cb4d6fa7de0c55b5e99b933dd7e7e21b273f5.o" "@dist\build\ld4BC5.rsp"
C:\msys64\home\ben\ghc-8.10.4\lib\../mingw/bin\ld.exe: dist\build\HSOpenGLRaw-3.3.4.1-4f4cb4d6fa7de0c55b5e99b933dd7e7e21b273f5.o: too many sections (80881)
C:\msys64\home\ben\ghc-8.10.4\lib\../mingw/bin\ld.exe: final link failed: file too big
C:\msys64\home\ben\ghc-8.10.4\lib\../mingw/bin\ld.exe returned ExitFailure 1

cabal.exe: Failed to build
OpenGLRaw-3.3.4.1-4f4cb4d6fa7de0c55b5e99b933dd7e7e21b273f5.
Failed to build tmp-0.1.0.0 because it depends on tmp-0.1.0.0 which itself
failed to build.

Expected behavior
The ld -r invocation should pass --oformat=pe-bigobj-x86-64, ensuring the build passes. Recent GHC versions expose the command and arguments that it would use to merge object files in the ghc --info output (the Merge objects command and Merge objects flags keys).

In general I think we should find a way to allow Cabal to delegate all linking to GHC. Linking is unfortunately a very subtle thing which requires quite some platform knowledge to get right. GHC already has this knowledge and it makes little sense to replicate it in Cabal.

System information

• Windows 10
• cabal-install-3.4.0.0
• ghc-8.10.4

Additional context
Add any other context about the problem here.

[Mikolaj]

Yes, please teach GHC to do that and we'd gladly conditionally change the ld calls to ghc calls when building packages with new enough GHC.

Edit: I guess we currently call ld not only on Widows? And we'd be able to deprecate calling ld on all platforms once GHC can handle that?

[bgamari]

Yes, please teach GHC to do that and we'd gladly conditionally change the ld calls to ghc calls when building packages with new enough GHC.

I have opened https://gitlab.haskell.org/ghc/ghc/-/issues/20712 to track the addition of a new object-joining mode.

Edit: I guess we currently call ld not only on Widows? And we'd be able to deprecate calling ld on all platforms once GHC can handle that?

Indeed.