Skip to content

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

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

Description

@chrisdone
chrisdone
opened on Mar 13, 2018

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?

Activity

  1. chrisdone
    changed the title [-]GHC 8.4 syntax error[/-] [+]GHC 8.4 syntax error (on Windows specifically; Linux and OS X are fine)[/+] on Mar 13, 2018

  2. kazu-yamamoto commented on Mar 13, 2018

    @kazu-yamamoto
    kazu-yamamoto
    on Mar 13, 2018
    Collaborator

    Strange. AppVeyor works well for the 2.6 branch.

    @Mistuke Do you have any ideas?

  3. Mistuke commented on Mar 13, 2018

    @Mistuke
    Mistuke
    on Mar 13, 2018
    Collaborator

    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.

  4. kazu-yamamoto commented on Mar 14, 2018

    @kazu-yamamoto
    kazu-yamamoto
    on Mar 14, 2018
    Collaborator

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

  5. DanBurton commented on Mar 16, 2018

    @DanBurton
    DanBurton
    on Mar 16, 2018

    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)

  6. ndmitchell commented on Mar 16, 2018

    @ndmitchell
    ndmitchell
    on Mar 16, 2018
    Contributor

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

  7. Mistuke commented on Mar 16, 2018

    @Mistuke
    Mistuke
    on Mar 16, 2018
    Collaborator

    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.

  8. RyanGlScott commented on Mar 17, 2018

    @RyanGlScott
    RyanGlScott
    on Mar 17, 2018
    Member

    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.)

  9. Mistuke commented on Mar 17, 2018

    @Mistuke
    Mistuke
    on Mar 17, 2018 via email
    Collaborator

  10. RyanGlScott commented on Mar 17, 2018

    @RyanGlScott
    RyanGlScott
    on Mar 17, 2018
    Member

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

    network/network.cabal

    Lines 82 to 83 in b548b0c

    extensions:
    CPP, DeriveDataTypeable, ForeignFunctionInterface, TypeSynonymInstances

  11. Mistuke commented on Mar 17, 2018

    @Mistuke
    Mistuke
    on Mar 17, 2018
    Collaborator

    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.

  12. ndmitchell commented on Mar 19, 2018

    @ndmitchell
    ndmitchell
    on Mar 19, 2018
    Contributor

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

  13. Mistuke commented on Mar 19, 2018

    @Mistuke
    Mistuke
    on Mar 19, 2018
    Collaborator

    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.

  14. ndmitchell commented on Mar 19, 2018

    @ndmitchell
    ndmitchell
    on Mar 19, 2018
    Contributor

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

  15. Mistuke commented on Mar 19, 2018

    @Mistuke
    Mistuke
    on Mar 19, 2018 via email
    Collaborator

  16. 27 remaining items

  17. Mistuke commented on May 27, 2018

    @Mistuke
    Mistuke
    on May 27, 2018
    Collaborator

    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?

  18. ndmitchell commented on May 27, 2018

    @ndmitchell
    ndmitchell
    on May 27, 2018
    Contributor

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

  19. Mistuke commented on May 27, 2018

    @Mistuke
    Mistuke
    on May 27, 2018
    Collaborator

    @ndmitchell I believe the 2.7 release should work.

  20. Mistuke commented on May 28, 2018

    @Mistuke
    Mistuke
    on May 28, 2018
    Collaborator

    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.

  21. kazu-yamamoto commented on May 28, 2018

    @kazu-yamamoto
    kazu-yamamoto
    on May 28, 2018
    Collaborator

    @Mistuke Would you make a PR?

  22. Mistuke commented on May 28, 2018

    @Mistuke
    Mistuke
    on May 28, 2018
    Collaborator

    Allright, sure

  23. Mistuke commented on May 28, 2018

    @Mistuke
    Mistuke
    on May 28, 2018
    Collaborator

    Done, see #323

  24. kazu-yamamoto commented on Jun 26, 2018

    @kazu-yamamoto
    kazu-yamamoto
    on Jun 26, 2018
    Collaborator

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

  25. kazu-yamamoto
    closed this as completedon Jun 26, 2018

  26. AndreiChugunov commented on Oct 14, 2018

    @AndreiChugunov
    AndreiChugunov
    on Oct 14, 2018

    @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.

  27. Mistuke commented on Oct 14, 2018

    @Mistuke
    Mistuke
    on Oct 14, 2018
    Collaborator

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

  28. AndreiChugunov commented on Oct 14, 2018

    @AndreiChugunov
    AndreiChugunov
    on Oct 14, 2018

    @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!

  29. Mistuke commented on Oct 14, 2018

    @Mistuke
    Mistuke
    on Oct 14, 2018 via email
    Collaborator

  30. AndreiChugunov commented on Oct 14, 2018

    @AndreiChugunov
    AndreiChugunov
    on Oct 14, 2018

    @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 :<

  31. Mistuke commented on Oct 14, 2018

    @Mistuke
    Mistuke
    on Oct 14, 2018 via email
    Collaborator
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions