GHC 8.4 syntax error (on Windows specifically; Linux and OS X are fine)

[chrisdone]

The following syntax error happens when compiling network-2.6.3.4 on Windows https://ci.appveyor.com/project/chrisdone/intero/build/1.0.260#L34319

34318    Preprocessing library for network-2.6.3.4..
34319    Building library for network-2.6.3.4..
34320    [1 of 9] Compiling Network.Socket.ByteString.Internal ( Network\Socket\ByteString\Internal.hs, .stack-work\dist\893fbf7f\build\Network\Socket\ByteString\Internal.o )
34321    [2 of 9] Compiling Network.Socket.Types ( .stack-work\dist\893fbf7f\build\Network\Socket\Types.hs, .stack-work\dist\893fbf7f\build\Network\Socket\Types.o )
34322    
34323    C:\Users\appveyor\AppData\Local\Temp\1\stack2232\network-2.6.3.4\Network\Socket\Types.hsc:764:16: error:
34324        parse error on input `CALLCONV'
34325        |
34326    764 | foreign import CALLCONV unsafe "ntohs" ntohs :: Word16 -> Word16
34327        |                ^^^^^^^^
34328
34329
34330--  While building custom Setup.hs for package hspec-discover-2.4.8 using:
34331      C:\sr\setup-exe-cache\i386-windows\Cabal-simple_Z6RU0evB_2.2.0.0_ghc-8.4.1.exe --builddir=.stack-work\dist\893fbf7f build --ghc-options " -ddump-hi -ddump-to-file"
34332    Process exited with code: ExitFailure (-1073741819)
34333    Logs have been written to: C:\stack\.stack-work\logs\hspec-discover-2.4.8.log
34334
34335

I suppose that calling convention syntax isn't allowed on Windows?

[kazu-yamamoto]

Strange. AppVeyor works well for the 2.6 branch.

@Mistuke Do you have any ideas?

[Mistuke]

The module is deferring #include <HsNetDef.h> (note the two #), so hsc2hs won't process the preprocessor macro.

Since it's been deferred you need to enable CPP to have GHC preprocess the hs file.
So add {-# LANGUAGE CPP #-} at the top and that should fix it.

[kazu-yamamoto]

@chrisdone Could you modify files according to @Mistuke's suggestion, confirm and send a PR?

[DanBurton]

I am not able to reproduce this error on my windows machine.

stack unpack network-2.6.3.4
cd network-2.6.3.4
notepad.exe stack.yaml # resolver: nightly-2018-03-16
stack build

Instead I merely get warnings that say:

* the 'stdcall' calling convention is unsupported on this platform
  treating as ccall

stack-1.6.5 (windows 64 bit version)
Windows 10 Home edition (64 bit)

[ndmitchell]

I am using 32bit GHC, which might be the difference

[Mistuke]

That's a different issue, that issue is that the definition of CALLCONV is wrong, it checks for _WIN32 which is also defined when the target is a 64 bit target https://msdn.microsoft.com/en-us/library/b0084kay.aspx

It should instead check for the GHC Macros we put out for this stuff like Win32 does or check _WIN64 first.

[RyanGlScott]

In that case, I'm extremely confused as to what is causing the original issue since, if I'm reading that correctly, CALLCONV should always be defined to something?

(I am also unable to reproduce the issue with 32-bit GHC 8.4.1.)

[Mistuke]

CALLCONV is never included correctly. I'm more confused by why it has been working thus far. The only time a preprocessor runs over this file is when it's told to skip processing of the include. So this shouldn't have ever worked. Unless hsc2hs had a bug or unexpected behavior

…

On Sat, Mar 17, 2018, 00:13 Ryan Scott ***@***.***> wrote: In that case, I'm extremely confused as to what is causing the original issue since, if I'm reading that correctly, CALLCONV should always be defined to *something*? (I am also unable to reproduce the issue with 32-bit GHC 8.4.1.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#313 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABH3KeWQ2xTpdQoe_EzIOzsAcA4PQA5cks5tfFU2gaJpZM4SoYfD> .

[RyanGlScott]

@Mistuke, CPP is set, in network.cabal:

network/network.cabal

Lines 82 to 83 in b548b0c

	extensions:
	CPP, DeriveDataTypeable, ForeignFunctionInterface, TypeSynonymInstances

[Mistuke]

Yes but whatever is processing the cabal file is not passing it along to the compiler as the preprocessor is not running. so my suggestion would still work.

I can't reproduce this issue with cabal-install nor with ghc 8.4. So it's not a network problem or a problem with the ghc HQ produced bindists.

the warning @ndmitchell is seeing I'll fix.

[ndmitchell]

It's not a warning, it's an error, and I'm seeing it with Stack i386 on Windows.

[Mistuke]

I meant the warning @DanBurton is seeing about the calling convention.

I don't think the error your seeing is a network bug.
You can try adding something like #error foo to HsNetDef.h to see if the preprocessor is being ran at all.

If you can paste the command the ghc command it's running for compiling Compiling Network.Socket.Types or the ghc -v3 output for this module that would help figure out what's wrong.

[ndmitchell]

I can't reproduce locally, but it very definitely happens on Appveyor repeatedly.

[Mistuke]

Can you pass -v3 to ghc and link back the appveyors log? Which windows is your appveyor instance based on? I remember there being two options.

…

On Mon, Mar 19, 2018, 19:22 Neil Mitchell ***@***.***> wrote: I can't reproduce locally, but it very definitely happens on Appveyor repeatedly. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#313 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABH3KSAwFgMU_FjtK7t3bTjjyyxrLcghks5tgAVhgaJpZM4SoYfD> .

[ndmitchell]

https://ci.appveyor.com/project/ndmitchell/neil/build/1.0.297 with -v3 to GHC. I don't know which Windows version it is, but its VS 2015 as my environment type.

[chrisdone]

If you add

init:
  - ps: iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))
on_finish:
  - ps: $blockRdp = $true; iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))

to your appveyor.yaml then you can login to the computer with RDP and debug what's going on live. The machine runs for 1 hour before shutting down. It shows the RPD login details, like this: https://ci.appveyor.com/project/chrisdone/rocksdb-haskell-ng/build/1.0.42#L3

You can clone intero or neil's repo and add appveyor on your account to do so. AppVeyor page on it.

[ndmitchell]

My appveyor does stack install network to reproduce, so suggest you start with that - happy to distill a direct appveyor script if that's the bottleneck.

[kazu-yamamoto]

CALLCONV is never included correctly. I'm more confused by why it has been working thus far.

@Mistuke In 2.6, CALLCONV is defined network.buildinfo. So, it is passed as CC options. This is very adhoc and ugly. So, I spent much time to remove this approach from master.

[kazu-yamamoto]

@ndmitchell @chrisdone I'm very confused. We did not change anythings relating to CALLCONV in 2.6.3.4.

• Is this specific to network v2.6.3.4?
• Is this specific to GHC 8.4?

[ndmitchell]

@kazu-yamamoto it started happening coincident with GHC 8.4, so does seem to be specific to that.

[kazu-yamamoto]

I have imported @Mistuke's #311 to a branch based on 2.6 and am seeing what will happen:

https://ci.appveyor.com/project/kazu-yamamoto/network

[chrisdone]

Looks like 8.4 succeeded: https://ci.appveyor.com/project/kazu-yamamoto/network/build/1.0.189/job/aa8qea0ckw152yps

[ndmitchell]

That's the head version of network, so it may be that network has been fixed in HEAD.

[chrisdone]

I can link to that commit in my stack.yaml and see if the intero repo builds.

[Mistuke]

Yeah, I didn't catch at all that 2.6 has a different way to define CALLCONV, I was operating under the assumption that it's the same code... can you add network.buildinfo as an artifact to your AppVeyor build @ndmitchell , that should provide some answers.

or you @chrisdone for the failing 2.6 build. Otherwise I'll try to set up appveyor later tonight.

[Mistuke]

Ah that makes more sense now. Thanks!

…

On Wed, Mar 21, 2018, 16:03 Neil Mitchell ***@***.***> wrote: x64 is broken too. I'll get the other info later tonight. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#313 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABH3KcKnHRm7mHZN4mdy7g3YOgFjRJpjks5tgnnWgaJpZM4SoYfD> .

[ndmitchell]

My desktop machine, which works:

C:\Neil\temp\i386\simple>autoreconf
'autoreconf' is not recognized as an internal or external command, operable program or batch file.
C:\Neil\temp\i386\simple>sed --version
GNU sed version 3.02
C:\Neil\temp\i386\simple>stack exec -- sh -c "autoreconf --version"
autoreconf (GNU Autoconf) 2.69
C:\Neil\temp\i386\simple>stack exec -- sh -c "sed --version"
sed (GNU sed) 4.4

The server, which doesn't work:

$ autoreconf
'autoreconf' is not recognized as an internal or external command, operable program or batch file.
$ sed --version
sed (GNU sed) 4.4
$ stack exec -- sh -c "sed --version"
sed (GNU sed) 4.2.2
$ stack exec -- sh -c "autoreconf --version"
Not found

So how is stack running without autoreconf? How are we meant to debug Stack? I think we need a Stack expert to help...

[kazu-yamamoto]

@ndmitchell Would you run stack exec which autoreconf on both machines and tell us what is printed?

[kazu-yamamoto]

I cannot reproduce the original CALLCONV issue found by @chrisdone. Test on 2.6 with GHC 8.4.1 has passed. Two versions of GHC failed (time out) but I believe it's a bug of test frame work. On master, after we switched to hspec, this phenomena is gone.

https://ci.appveyor.com/project/eborden/network/build/377

[kazu-yamamoto]

If people wish, I can introduce master's clean build approach and hspec to 2.6.

[kazu-yamamoto]

I have imported Hspec testing from master to both 2.6 and 2.7. Travis and Appvoyer pass perfectly.

[ndmitchell]

I raised this as a Stack bug at commercialhaskell/stack#3944 since stack can compile network one way, but not the other, suggesting there is a different in environment between the two invocations.

[Mistuke]

I think it's pretty clear this is a stack issue. I think we should close this as there's nothing we can do about it downstream. Master no longer uses this approach, so a possible solution is to update to a newer network?

[ndmitchell]

@Mistuke - is there a release using the new approach?

[Mistuke]

@ndmitchell I believe the 2.7 release should work.

[Mistuke]

Ah no, looking at the tag it doesn't. @kazu-yamamoto maybe it's worth including the CALLCONV changes into the 2.7.0.1 release in #322 ? That should fix network on stack.

[kazu-yamamoto]

@Mistuke Would you make a PR?

[Mistuke]

Allright, sure

[Mistuke]

Done, see #323

[kazu-yamamoto]

I would like to close this. Please reopen this if necessary.

[AndreiChugunov]

@kazu-yamamoto @Mistuke Not sure if i m writing where it is needed but i got the same problem while building network-2.6.3.6 on windows 10. ghc 8.4.3.

[Mistuke]

@AndreiChugunov You should use 2.7, that should be working.

[AndreiChugunov]

@Mistuke I'm sorry i'm new to stack and haskell overall. I have dependencies in my package.yaml:
dependencies:

• base >= 4.7 && < 5
• servant-server
• aeson
• wai
• warp

Is seems like aeson needs a network library. How can i specify i need network-2.7 not 2.6.3.6? Can i just simply write it down in dependecies section in package.yaml? Thanks a lot for your fast reply and help!

[Mistuke]

Hmm sorry I'm not that familiar with stack. You probably need a newer resolver? With cabal it would be `--allow-newer`. Maybe someone else here knows how to get 2.7 with stack.

…

On Sun, Oct 14, 2018, 13:41 AndreiChugunov ***@***.***> wrote: @Mistuke <https://github.com/Mistuke> I'm sorry i'm new to stack and haskell overall. I have dependencies in my package.yaml: dependencies: - base >= 4.7 && < 5 - servant-server - aeson - wai - warp Is seems like aeson needs a network library. How can i specify i need network-2.7 not 2.6.3.6? Can i just simply write it down in dependecies section in package.yaml? Thanks a lot for your fast reply and help! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#313 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABH3KQ2HwMx-8or4j0cfy23xZ0ek3dlfks5ukzEQgaJpZM4SoYfD> .

[AndreiChugunov]

@Mistuke ugh. I specified version of network to 2.7.0.2. And it seems to build successfully but for now i get the following error " unable to load package network-2.7.0.2 ":
`Error:
-- While building custom Setup.hs for package wai-app-static-3.1.6.2 using:
C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.2.0.1_ghc-8.4.3.exe --builddir=.stack-work\dist\7d103d30 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
Logs have been written to: C:\Users\809279\Desktop\testBuild\testProj.stack-work\logs\wai-app-static-3.1.6.2.log

Configuring wai-app-static-3.1.6.2...
Preprocessing library for wai-app-static-3.1.6.2..
Building library for wai-app-static-3.1.6.2..
[1 of 9] Compiling WaiAppStatic.Types ( WaiAppStatic\Types.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Types.o )
[2 of 9] Compiling Util             ( Util.hs, .stack-work\dist\7d103d30\build\Util.o )
[3 of 9] Compiling WaiAppStatic.Listing ( WaiAppStatic\Listing.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Listing.o )

WaiAppStatic\Listing.hs:67:34: warning: [-Wname-shadowing]
    This binding for `pieces' shadows the existing binding
      bound at WaiAppStatic\Listing.hs:27:16
   |
67 |     showFolder' hasTrailingSlash pieces  = showFolder hasTrailingSlash (unsafeToPiece "root" : pieces)
   |                                  ^^^^^^

WaiAppStatic\Listing.hs:120:24: warning: [-Wunused-local-binds]
    Defined but not used: `isFile'
    |
120 |                    let isFile = either (const False) (const True) md
    |                        ^^^^^^
[4 of 9] Compiling WaiAppStatic.Storage.Filesystem ( WaiAppStatic\Storage\Filesystem.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Storage\Filesystem.o )
[5 of 9] Compiling WaiAppStatic.Storage.Embedded.TH ( WaiAppStatic\Storage\Embedded\TH.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Storage\Embedded\TH.o )

WaiAppStatic\Storage\Embedded\TH.hs:10:1: warning: [-Wunused-imports]
    The import of `Control.Applicative' is redundant
      except perhaps to import instances from `Control.Applicative'
    To import instances alone, use: import Control.Applicative()
   |
10 | import Control.Applicative
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^
[6 of 9] Compiling WaiAppStatic.Storage.Embedded.Runtime ( WaiAppStatic\Storage\Embedded\Runtime.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Storage\Embedded\Runtime.o )
[7 of 9] Compiling WaiAppStatic.Storage.Embedded ( WaiAppStatic\Storage\Embedded.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Storage\Embedded.o )
[8 of 9] Compiling Network.Wai.Application.Static ( Network\Wai\Application\Static.hs, .stack-work\dist\7d103d30\build\Network\Wai\Application\Static.o )
ghc.EXE: unable to load package `network-2.7.0.2'
ghc.EXE:  | C:\Users\809279\Desktop\testBuild\testProj\.stack-work\install\c4f08ade\lib\x86_64-windows-ghc-8.4.3\network-2.7.0.2-HRKpEmrZF0Z7oBCs9x5PCR\HSnetwork-2.7.0.2-HRKpEmrZF0Z7oBCs9x5PCR.o: unknown symbol `acceptNewSock'`

Is it a known error? Seems like it is the last error i have to fix :<

[Mistuke]

Seems like the preprocessor went wrong. See https://www.fpcomplete.com/blog/2018/06/sed-a-debugging-story if the fix there works for you.

…

On Sun, Oct 14, 2018, 16:07 AndreiChugunov ***@***.***> wrote: @Mistuke <https://github.com/Mistuke> ugh. I specified version of network to 2.7.0.2. And it seems to build successfully but for now i get the following error " unable to load package network-2.7.0.2' ":Error: -- While building custom Setup.hs for package wai-app-static-3.1.6.2 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.2.0.1_ghc-8.4.3.exe --builddir=.stack-work\dist\7d103d30 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Logs have been written to: C:\Users\809279\Desktop\testBuild\testProj.stack-work\logs\wai-app-static-3.1.6.2.log Configuring wai-app-static-3.1.6.2... Preprocessing library for wai-app-static-3.1.6.2.. Building library for wai-app-static-3.1.6.2.. [1 of 9] Compiling WaiAppStatic.Types ( WaiAppStatic\Types.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Types.o ) [2 of 9] Compiling Util ( Util.hs, .stack-work\dist\7d103d30\build\Util.o ) [3 of 9] Compiling WaiAppStatic.Listing ( WaiAppStatic\Listing.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Listing.o ) WaiAppStatic\Listing.hs:67:34: warning: [-Wname-shadowing] This binding for `pieces' shadows the existing binding bound at WaiAppStatic\Listing.hs:27:16 | 67 | showFolder' hasTrailingSlash pieces = showFolder hasTrailingSlash (unsafeToPiece "root" : pieces) | ^^^^^^ WaiAppStatic\Listing.hs:120:24: warning: [-Wunused-local-binds] Defined but not used: `isFile' | 120 | let isFile = either (const False) (const True) md | ^^^^^^ [4 of 9] Compiling WaiAppStatic.Storage.Filesystem ( WaiAppStatic\Storage\Filesystem.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Storage\Filesystem.o ) [5 of 9] Compiling WaiAppStatic.Storage.Embedded.TH ( WaiAppStatic\Storage\Embedded\TH.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Storage\Embedded\TH.o ) WaiAppStatic\Storage\Embedded\TH.hs:10:1: warning: [-Wunused-imports] The import of `Control.Applicative' is redundant except perhaps to import instances from `Control.Applicative' To import instances alone, use: import Control.Applicative() | 10 | import Control.Applicative | ^^^^^^^^^^^^^^^^^^^^^^^^^^ [6 of 9] Compiling WaiAppStatic.Storage.Embedded.Runtime ( WaiAppStatic\Storage\Embedded\Runtime.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Storage\Embedded\Runtime.o ) [7 of 9] Compiling WaiAppStatic.Storage.Embedded ( WaiAppStatic\Storage\Embedded.hs, .stack-work\dist\7d103d30\build\WaiAppStatic\Storage\Embedded.o ) [8 of 9] Compiling Network.Wai.Application.Static ( Network\Wai\Application\Static.hs, .stack-work\dist\7d103d30\build\Network\Wai\Application\Static.o ) ghc.EXE: unable to load package `network-2.7.0.2' ghc.EXE: | C:\Users\809279\Desktop\testBuild\testProj\.stack-work\install\c4f08ade\lib\x86_64-windows-ghc-8.4.3\network-2.7.0.2-HRKpEmrZF0Z7oBCs9x5PCR\HSnetwork-2.7.0.2-HRKpEmrZF0Z7oBCs9x5PCR.o: unknown symbol `acceptNewSock'` Is it a known error? Seems like it is the last error i have to fix :< — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#313 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABH3KQsWoxYoPWPmCHRUg_aIUALKDvfeks5uk1McgaJpZM4SoYfD> .