While the comment says that this is meant for Linux, this also takes effect on Windows. One consequence of defining this macro on Windows is that when the sprintf function is called later:
Then GHC will link against the mingwex library. Prior to GHC 9.4.5, GHC would implicitly link against mingwex by default, but this is no longer the case with GHC 9.4.5, GHC 9.6.1, or later. This manifests as a linker error when loading network with GHC's runtime linker (e.g., when performing a Template Haskell splice involving network), as seen in the following places:
$ cabal test -w ghc-9.6
Build profile: -w ghc-9.6.1 -O1
In order, the following will be built (use -v for more details):
- network-3.1.2.8 (file tests\Network\SocketSpec.hs changed)
Preprocessing library for network-3.1.2.8..
Building library for network-3.1.2.8..
Preprocessing test suite 'spec' for network-3.1.2.8..
Building test suite 'spec' for network-3.1.2.8..
[2 of 5] Compiling Network.SocketSpec ( tests\Network\SocketSpec.hs, C:\\Users\winferno\Documents\Hacking\Haskell\network\dist-ne
wstyle\build\x86_64-windows\ghc-9.6.1\network-3.1.2.8\build\spec\spec-tmp\Network\SocketSpec.o ) [Source file changed]
ghc-9.6.1.exe: | C:\Users\winferno\Documents\Hacking\Haskell\network\dist-newstyle\build\x86_64-windows\ghc-9.6.1\network-3.1.2.
8\build\libHSnetwork-3.1.2.8-inplace.a: unknown symbol `__mingw_vsprintf'
ghc-9.6.1.exe: | C:\Users\winferno\Documents\Hacking\Haskell\network\dist-newstyle\build\x86_64-windows\ghc-9.6.1\network-3.1.2.
8\build\libHSnetwork-3.1.2.8-inplace.a: unknown symbol `getWSErrorDescr'
ghc-9.6.1.exe: ^^ Could not load 'networkzm3zi1zi2zi8zminplace_NetworkziSocketziInternal_throwSocketErrorCode_closure', dependenc
y unresolved. See top entry above.
<no location info>: error:
GHC.ByteCode.Linker.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
networkzm3zi1zi2zi8zminplace_NetworkziSocketziInternal_throwSocketErrorCode_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please report this as a GHC bug:
https://www.haskell.org/ghc/reportabug
Note the mention of __mingw_vsprintf in the linker error. The fact that GHC attempts to link against this function is a direct consequence of defining _GNU_SOURCE, as this is what sprintf calls when _GNU_SOURCE is enabled.
Solution
The most direct way to avoid this issue is to avoid defining _GNU_SOURCE at all on Windows. There is no particular reason to use _GNU_SOURCE on Windows, as all of the C code used on Windows is quite standard. I will submit a patch momentarily.
This issue was spun out of GHC#23309. To summarize that issue,
network
'sHsNet.h
file currently defines the_GNU_SOURCE
macro:https://github.com/haskell/network/blob/84466653f42e0a2e79fc1041d333b0dcb2ea7017/include/HsNet.h#L22
While the comment says that this is meant for Linux, this also takes effect on Windows. One consequence of defining this macro on Windows is that when the
sprintf
function is called later:https://github.com/haskell/network/blob/3ffe896a4686fd0da14dc34373e7ee56078ad63b/cbits/winSockErr.c#L70
Then GHC will link against the
mingwex
library. Prior to GHC 9.4.5, GHC would implicitly link againstmingwex
by default, but this is no longer the case with GHC 9.4.5, GHC 9.6.1, or later. This manifests as a linker error when loadingnetwork
with GHC's runtime linker (e.g., when performing a Template Haskell splice involvingnetwork
), as seen in the following places:Cabal
: https://github.com/haskell/cabal/issues/8858hpack
: https://github.com/sol/hpack/pull/548hakyll
: https://github.com/jaspervdj/hakyll/issues/986A simpler way to reproduce the issue is to apply the following patch in
network
:And then run
cabal test
with GHC 9.4.5 or later:Note the mention of
__mingw_vsprintf
in the linker error. The fact that GHC attempts to link against this function is a direct consequence of defining_GNU_SOURCE
, as this is whatsprintf
calls when_GNU_SOURCE
is enabled.Solution
The most direct way to avoid this issue is to avoid defining
_GNU_SOURCE
at all on Windows. There is no particular reason to use_GNU_SOURCE
on Windows, as all of the C code used on Windows is quite standard. I will submit a patch momentarily.