Windows, foreign-library, Cabal-3.10.3.0 regression in linker

[mpilgrem]

I have a simple package foo with Cabal file:

cabal-version:  2.2
name:           foo
version:        0.1.0.0
foreign-library foo
  type:             native-shared
  other-modules:    Lib
  hs-source-dirs:   src
  build-depends:    base >=4.7 && <5
  default-language: Haskell2010
  if os(windows)
    options:        standalone

With GHC 9.6.4/Cabal-3.10.1.0 it builds fine:

❯ stack --snapshot ghc-9.6.4 build
foo> configure
foo> Configuring foo-0.1.0.0...
foo> build with ghc-9.6.4
foo> Preprocessing foreign library 'foo' for foo-0.1.0.0..
foo> Building foreign library 'foo' for foo-0.1.0.0..
foo> [1 of 1] Compiling Lib
foo> [1 of 2] Compiling Lib [Flags changed]
foo> [2 of 2] Linking .stack-work\dist\ab060f89\build\foo\foo.dll

With GHC 9.6.5/Cabal-3.10.3.0 the build fails in the linker:

❯ stack --snapshot ghc-9.6.5 build
foo> configure
foo> Configuring foo-0.1.0.0...
foo> build with ghc-9.6.5
foo> Preprocessing foreign library 'foo' for foo-0.1.0.0..
foo> Building foreign library 'foo' for foo-0.1.0.0..
foo> [1 of 1] Compiling Lib
foo> [1 of 2] Compiling Lib [Flags changed]
foo> [2 of 2] Linking .stack-work\dist\eebe39f7\build\foo\foo.dll
foo> lld: error: unknown argument: -rpath
foo> lld: error: unknown argument: -rpath
foo> clang: error: linker command failed with exit code 1 (use -v to see invocation)
foo> ghc-9.6.5.exe: `clang.exe' failed in phase `Linker'. (Exit code: 1)

Error: [S-7282]
       Stack failed to execute the build plan.

       While executing the build plan, Stack encountered the error:

       [S-7011]
       While building package foo-0.1.0.0 (scroll up to its section to see the error) using:
       D:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_7psHxtdj_3.10.3.0_ghc-9.6.5.exe --verbose=1 --builddir=.stack-work\dist\eebe39f7 build --ghc-options " -fdiagnostics-color=always"
       Process exited with code: ExitFailure 1

Is this a regression introduced in Cabal-3.10.3.0? I wondered if it was related to:

• The ghc-options are not passed to the linker #9589 (EDIT: I now think that's unrelated)

EDIT: I am pretty sure that this is a regession between Cabal-3.10.1.0 and Cabal-3.10.3.0 because my example builds if I force Stack to build using GHC 9.6.5 but with Cabal-3.10.1.0, using:

cabal-version:  2.2
name:           foo
version:        0.1.0.0
build-type:     Custom

custom-setup
  setup-depends:   base >= 4.7 && < 5
                 , Cabal ==3.10.1.0
                 , Cabal-syntax ==3.10.1.0

foreign-library foo
  type:             native-shared
  other-modules:    Lib
  hs-source-dirs:   src
  build-depends:    base >=4.7 && <5
  default-language: Haskell2010
  if os(windows)
    options:        standalone

EDIT2: Using the same method, it appears to me to be a regression introduced between Cabal-3.10.2.1 and Cabal-3.10.3.0.

(EDIT 3: The good news is this is not a problem for GHC 9.10.0.20240426/Cabal-3.12.0.0.)

[mpilgrem]

A difference between the two builds above is that, in the linking step, Cabal calls GHC 9.6.5 with additional arguments not present in the GHC 9.6.4 example:

"-dynload deploy" 
"-optl-Wl,-rpath,D:\sr\programs\x86_64-windows\msys2-20230526\mingw64\lib" 
"-optl-Wl,-rpath,D:\sr\programs\x86_64-windows\msys2-20230526\mingw64\bin" 

[mpilgrem]

Looking at: https://downloads.haskell.org/~ghc/9.6.5/docs/users_guide/shared_libs.html#finding-shared-libraries-at-runtime, I get the impression that -dynload deploy may be a GHC option that is not applicable on Windows.

[juhp]

Is there a corresponding ghc issue open?
(I am thinking in terms of fixing for 9.6.6 and 9.8.3 etc)

[mpilgrem]

I don't think so - looks to me like a regression introduced into Cabal, not GHC. EDIT: unless you mean something to warn the GHC developers that there is this problem with that version of Cabal?

[jasagredo]

This seems to work for me:

➜ cabal build
Resolving dependencies...
Build profile: -w ghc-9.6.6 -O1
In order, the following will be built (use -v for more details):
 - bb-0.1.0.0 (flib:bb) (first run)
Configuring foreign library 'bb' for bb-0.1.0.0...
Preprocessing foreign library 'bb' for bb-0.1.0.0...
Building foreign library 'bb' for bb-0.1.0.0...
[1 of 1] Compiling MyLib            ( src\MyLib.hs, C:\Users\Javier\bb\dist-newstyle\build\x86_64-windows\ghc-9.6.6\bb-0.1.0.0\f\bb\build\bb\bb-tmp\MyLib.o )
[1 of 2] Compiling MyLib            ( src\MyLib.hs, C:\Users\Javier\bb\dist-newstyle\build\x86_64-windows\ghc-9.6.6\bb-0.1.0.0\f\bb\build\bb\bb-tmp\MyLib.o ) [Flags changed]
[2 of 2] Linking C:\\Users\\Javier\\bb\\dist-newstyle\\build\\x86_64-windows\\ghc-9.6.6\\bb-0.1.0.0\\f\\bb\\build\\bb\\bb.dll

With your .cabal description above.

[ysangkok]

GHC 9.6.7 is now the recommended version in GHCup, and it has Cabal-3.10.3.0, so I suppose we'll see if more people will be hitting this bug soon...

[pillowtrucker]

I only hit it because I revived a windows build box from hibernation but simply updating ghc and cabal with ghcup fixed it. Recommended cabal is 3.12.x there.

[ysangkok]

@pillowtrucker There is a difference between Cabal (the library) and cabal-install, the executable. The "cabal" you see in GHCup is cabal-install. I think this issue is about Cabal (the library) since there is no mention of cabal-install and Cabal is consistently capitalised within this thread. Even if the recommended version of cabal-install in GHCup is a recent version, GHCup will not swap out the major version linked into the GHC executable, which remains 3.10 in the GHC 9.6 series.