static building of executables fail on Windows 10

[vu3rdd]

I am using cabal version 2.4.1.0 and am building a project which depends on another package that has a C dependency. I use LIBRARY_PATH variable to point to the library. Dynamic linking works and the program runs fine.

However, building a static executable using the command line flag --disable-executable-dynamic fails. During the first build, it failed this way:

C:\work\wormhole-client>cabal new-build  --disable-executable-dynamic
Build profile: -w ghc-8.4.3 -O1
In order, the following will be built (use -v for more details):
 - hwormhole-0.2.0.0 (lib) (configuration changed)
 - hwormhole-0.2.0.0 (exe:hwormhole-exe) (dependency rebuilt)
Configuring library for hwormhole-0.2.0.0..
Preprocessing library for hwormhole-0.2.0.0..
Building library for hwormhole-0.2.0.0..
Preprocessing executable 'hwormhole-exe' for hwormhole-0.2.0.0..
Building executable 'hwormhole-exe' for hwormhole-0.2.0.0..
Linking C:\work\wormhole-client\dist-newstyle\build\x86_64-windows\ghc-8.4.3\hwormhole-0.2.0.0\x\hwormhole-exe\build\hwormhole-exe\hwormhole-exe.exe ...
C://ProgramData//chocolatey//lib//ghc//tools//ghc-8.4.3//mingw//bin/ld.exe: cannot find -lsodium
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)

Subsequent invocation of the same command yielded a success, though the executable was not created.

C:\work\wormhole-client>cabal new-build  --disable-executable-dynamic
Up to date

C:\work\wormhole-client>dir C:\work\wormhole-client\dist-newstyle\build\x86_64-windows\ghc-8.4.3\hwormhole-0.2.0.0\x\hwormhole-exe\build\hwormhole-exe\
 Volume in drive C has no label.
 Volume Serial Number is 22B6-504B

 Directory of C:\work\wormhole-client\dist-newstyle\build\x86_64-windows\ghc-8.4.3\hwormhole-0.2.0.0\x\hwormhole-exe\build\hwormhole-exe

12/11/2018  12:39 PM    <DIR>          .
12/11/2018  12:39 PM    <DIR>          ..
12/11/2018  12:05 PM    <DIR>          autogen
12/11/2018  12:05 PM    <DIR>          hwormhole-exe-tmp
               0 File(s)              0 bytes
               4 Dir(s)  32,039,825,408 bytes free

Is creation of static binaries supported on Windows? It would be very nice to have it supported as it helps ship binaries to users much easily. Thanks.

[Mistuke]

C://ProgramData//chocolatey//lib//ghc//tools//ghc-8.4.3//mingw//bin/ld.exe: cannot find -lsodium
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)

The linker is telling you it can't find a static version of your sodium library. Do you have one? and is it on a path ghc knows about?

[vu3rdd]

Yes, I passed it via the environment variable LIBRARY_PATH before invoking cabal. I am also puzzled why the same error didn't show up on subsequent invocations.

On Sun, Dec 16, 2018, at 6:39 PM, Tamar Christina wrote: C://ProgramData//chocolatey//lib//ghc//tools//ghc- 8.4.3//mingw//bin/ld.exe: cannot find -lsodium collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) > The linker is telling you it can't find a static version of your sodium library. Do you have one? and is it on a path ghc knows about?> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub[1], or mute the thread[2].

-- Ramakrishnan Links: 1. #5791 (comment) 2. https://github.com/notifications/unsubscribe-auth/AAB4QYTRLF4lnWLTQ8OkABmD3py7VcN6ks5u5kX3gaJpZM4ZPTKu

[vu3rdd]

I am happy to run any specific commands or collect more data to help debug the problem.

…

-- Ramakrishnan

[Mistuke]

Due to #5788 you can't currently do this on the commandline, but in your cabal file add

ghc-options: -optl-debug -optl-Wl,-M and pipe the whole thing to a file.

My guess is that your libsodium.a isn't on your library path or that you're confusing GHC by not telling it about the path (I don't remember at which version GHC started reading LIBRARY_PATH).

You can also try using extra-lib-dirs: instead of LIBRARY_PATH and seeing if that works.

I am also puzzled why the same error didn't show up on subsequent invocations.

Probably a bug in the recompilation avoidance of GHC. It probably assumed the binary was already created since no input files changed so it never attempted to relink. ld doesn't create intermediate files so that hwormhole-exe-tmp didn't come from it.

[vu3rdd]

Due to #5788 you can't currently do this on the commandline, but in your cabal file add

ghc-options: -optl-debug -optl-Wl,-M and pipe the whole thing to a file.

Thanks. I will try this when I get back in front of the windows computer and report back.

My guess is that your libsodium.a isn't on your library path or that you're confusing GHC by not telling it about the path (I don't remember at which version GHC started reading LIBRARY_PATH).

You can also try using extra-lib-dirs: instead of LIBRARY_PATH and seeing if that works.

In fact I tried this first while I was building dynamically linked executables and it was getting ignored. I grep'ed through the GHC sources and found the LIBRARY_PATH which worked while building dynamically linked binaries.

I am also puzzled why the same error didn't show up on subsequent invocations.

Probably a bug in the recompilation avoidance of GHC. It probably assumed the binary was already created since no input files changed so it never attempted to relink. ld doesn't create intermediate files so that hwormhole-exe-tmp didn't come from it.

Thanks, I will file a bug against GHC and try to trace through the execution. Seem like a good bug to pick up and try to contribute to the GHC.

[jneira]

@vu3rdd did you have the opportunity of recollect the logs with the suggested ghc options? maybe it would be good to try again with a newer version of cabal, thanks!

(btw #5788 seems to be fixed so you could use --ghc-options)