Don't declare _GNU_SOURCE on Windows #551
Description
This issue was spun out of GHC#23309. To summarize that issue, network's HsNet.h file currently defines the _GNU_SOURCE macro:
Line 22 in 8446665
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:
Line 70 in 3ffe896
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: cabal-testsuite fails early on with linker error on Windows since GHC 9.6 cabal#8858hpack: Relax upper bound on Cabal dependency sol/hpack#548hakyll: Fails to build on Windows with GHC 9.6.1 jaspervdj/hakyll#986
A simpler way to reproduce the issue is to apply the following patch in network:
diff --git a/network.cabal b/network.cabal
index a1b7a6d..e3cc217 100644
--- a/network.cabal
+++ b/network.cabal
@@ -188,7 +188,9 @@ test-suite spec
network,
temporary,
hspec >=2.6,
- QuickCheck
+ QuickCheck,
+
+ template-haskell
if flag(devel)
cpp-options: -DDEVELOPMENT
diff --git a/tests/Network/SocketSpec.hs b/tests/Network/SocketSpec.hs
index 743db7a..0766ced 100644
--- a/tests/Network/SocketSpec.hs
+++ b/tests/Network/SocketSpec.hs
@@ -1,5 +1,7 @@
{-# LANGUAGE CPP #-}
{-# LANGUAGE OverloadedStrings #-}
+{-# LANGUAGE ScopedTypeVariables #-}
+{-# LANGUAGE TemplateHaskell #-}
module Network.SocketSpec (main, spec) where
@@ -19,6 +21,13 @@ import Foreign.C.Types ()
import Test.Hspec
import Test.QuickCheck
+import Control.Exception (SomeException, catch)
+import qualified Language.Haskell.TH as TH
+import Network.Socket.Internal (throwSocketErrorCode)
+$(do TH.runIO $
+ throwSocketErrorCode "uh-oh" 432432432432 `catch` \(_ :: SomeException) -> putStrLn "PHEW"
+ return [])
+
main :: IO ()
main = hspec spec
And then run cabal test with GHC 9.4.5 or later:
$ 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.