search

commercialhaskell / stack

The Haskell Tool Stack
http://haskellstack.org
BSD 3-Clause "New" or "Revised" License
4k stars 843 forks source link

GHC panic when building Stack on macOS Sierra #2577

Closed bitemyapp closed 7 years ago

bitemyapp commented 8 years ago

GHC 7.10.3

stack upgrade --git
$ uname -a
Darwin cumae.local 16.0.0 Darwin Kernel Version 16.0.0: Tue Aug 23 17:02:44 PDT 2016; root:xnu-3789.1.31~2/RELEASE_X86_64 x86_64

Xcode 8.0 GM, macOS Sierra

Preprocessing library stack-1.2.1...
[ 1 of 96] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o )
[ 2 of 96] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o )
[ 3 of 96] Compiling Stack.FileWatch  ( src/Stack/FileWatch.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o )
[ 4 of 96] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o )
[ 5 of 96] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o )
[ 6 of 96] Compiling Paths_stack      ( .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o )
[ 7 of 96] Compiling Path.Find        ( src/Path/Find.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o )
[ 8 of 96] Compiling Path.Extra       ( src/Path/Extra.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o )
[ 9 of 96] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.3 for x86_64-apple-darwin):
        Loading temp shared object failed: dlopen(/var/folders/79/6lft40kj3cqb9f08_8yfg3vr0000gn/T/ghc29687_0/libghc_55.dylib, 5): no suitable image found.  Did find:
        /var/folders/79/6lft40kj3cqb9f08_8yfg3vr0000gn/T/ghc29687_0/libghc_55.dylib: malformed mach-o: load commands size (46680) > 32768

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Completed 178 action(s).

--  While building package stack-1.2.1 using:
      /private/var/folders/79/6lft40kj3cqb9f08_8yfg3vr0000gn/T/stack-upgrade18342/stack/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
ilovezfs commented 8 years ago

@borsboom I've now shipped bottles for Sierra: https://github.com/Homebrew/homebrew-core/commit/c1dce9063bd30c97635f16e54bc8324bbecb2210

simon-nicholls commented 8 years ago

Thanks. The Sierra bottle works in my (study) environment.

bitemyapp commented 8 years ago

I'm not using brew-installed stack, but binary manually-installed one, and I'm still having the problem (on a rather big project).

I was fine compiling a Servant project, but the yesod-simple scaffold still trips this for me.

ilovezfs commented 8 years ago

Yes, yesod* is known to be affected. GHC/Cabal needs to fix this. Listing affected projects here won't improve the situation.

bitemyapp commented 8 years ago

Sure, I'm reading along with https://ghc.haskell.org/trac/ghc/ticket/12479 to see where they've gotten so far.

ilovezfs commented 8 years ago

It looks like a fix is now on the way https://github.com/haskell/cabal/pull/3979.

shanemikel commented 8 years ago

Now that we have haskell/cabal#3982 and haskell/cabal#3983, has there been any thought about "teaching [stack] the new flags?"

23Skidoo commented 8 years ago

We probably won't be adding new flags to Cabal after all and go with an updated version of https://github.com/haskell/cabal/pull/3979. Instead GHC 8.0.2 will gain some new flags.

nedSaf commented 8 years ago

What's the status on this issue ? If it's resolved, what we should do to fix it on MacOS Sierra ?

Tehnix commented 8 years ago

It wasn't entirely clear to me (or maybe I just hope I'm wrong) from haskell/cabal#3979, and the other tickets etc, but does that mean that only GHC 8.0.2 and forward will build on macOS Sierra, and older GHC versions will still have the same problem?

borsboom commented 8 years ago

@Tehnix that is usually how it's gone in the past, unfortunately (e.g GHC 7.8.4 is broken on Yosemite and up). These kinds of fixes haven't been back-ported. However, if a volunteer wants to take on backporting, we could have Stack use a backported fixed version when it needs to.

cartazio commented 8 years ago

It's fixed in 8.0.2 and associated cabal

On Sunday, October 23, 2016, Nader Safadi notifications@github.com wrote:

What's the status on this issue ? If it's resolved, what we should do to fix it on MacOS Sierra ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/commercialhaskell/stack/issues/2577#issuecomment-255594555, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAQwhd2VLlnY-YbVpUoKrGVPMnOkxJ1ks5q23vDgaJpZM4J546w .

skull-squadron commented 8 years ago

For maintainers, something to consider Late to the party: On macOS, Homebrew casks are typically used for complex/isolated/versioned (i.e., ChefDK, TeX Live and maybe stack) binary (i.e., .dmg, .pkgs, etc.) distributions. Whereas brew formulas are typically preferred for hackable/component software built from source (although bottles are pre-built binaries of the formula). Some people may want brew formulas, but a complete, vendored-dependencies, binary distribution is usually easier, cheaper and less error-prone to both deploy and support. (Casks are awesome because it's like a centralized CLI Sparkle for full lifecycle mgmt, i.e., update everything: brew cask update.)

shanemikel commented 8 years ago

@steakknife are you sure you're in the right thread?

skull-squadron commented 8 years ago

@shanemikel I encountered this issue some time ago. Most recently addressing commercial haskell people and others whom may need to think about process improvement in release engineering to reduce community/ development support burden. Don't have time to find the appropriate feedback channel. Good luck, hope it works out.

cartazio commented 8 years ago

Older ghc will work fine as long as there's no use of th in packages that have as many transitive dynamic library deps as the union of snap and yesod. Also can mitigate by making sure the paths are shorter to the dynamic libs.

Alternatively a build of ghc that uses the ghci static linker for ghci on OS X would also dodge this issue.

Tehnix commented 8 years ago

@borsboom makes sense if that is what's usually done. I think I'll rather hope for the packages/libraries I use to be updated and perhaps help with that :)

@cartazio Unfortunately my use case is actually specifically for Yesod, so that leaves me on either 8.0.2+ for macOS Sierra, or using docker (which is quite easy with stack luckily, but sometimes hangs on the linking phase).

chadbrewbaker commented 7 years ago

The yesod-sqlite template is still busted on Sierra. If GHC < 8.0.2 is busted on OSX Sierra, shouldn't there be a LTS that supports this? LTS Haskell 7.10 is ghc-8.0.1.

shanemikel commented 7 years ago

@chadbrewbaker as of the time of this comment, the progress is at 99%. https://ghc.haskell.org/trac/ghc/roadmap

There's an open issue on this repo for backporting the relevant fixes (which I believe are available now), but... Well you can see for yourself, nobody's done it yet.

ilovezfs commented 7 years ago

Sources for Sierra's dyld have now been posted:

https://opensource.apple.com/source/dyld/dyld-421.1/

https://opensource.apple.com/tarballs/dyld/dyld-421.1.tar.gz

https://opensource.apple.com/source/dyld/dyld-421.1/src/ImageLoader.h.auto.html

#define MAX_MACH_O_HEADER_AND_LOAD_COMMANDS_SIZE (32*1024)

https://opensource.apple.com/source/dyld/dyld-421.1/src/ImageLoaderMachO.cpp.auto.html

if ( sizeofcmds > (MAX_MACH_O_HEADER_AND_LOAD_COMMANDS_SIZE-sizeof(macho_header)) )
        dyld::throwf("malformed mach-o: load commands size (%u) > %u", sizeofcmds, MAX_MACH_O_HEADER_AND_LOAD_COMMANDS_SIZE);

Note the changes from El Capitan https://opensource.apple.com/source/dyld/dyld-360.22/src/ImageLoaderMachO.cpp.auto.html

Other Sierra sources: https://opensource.apple.com/release/os-x-1012.html

alexanderkjeldaas commented 7 years ago

GHC-8.0.2 RC1 is out http://downloads.haskell.org/~ghc/8.0.2-rc1/

ilovezfs commented 7 years ago

@alexanderkjeldaas and that is what the Homebrew Sierra bottle is currently, btw.

ilovezfs commented 7 years ago

@borsboom given that GHC and Cabal have both been fixed, should the "resolution: upstream issue" tag be removed from this issue, since the only remaining problems are actually internal to stack itself?

Tehnix commented 7 years ago

@ilovezfs are you doing anything special to get brew to download 8.0.2? I'm on macOS Sierra and running brew update && brew install ghc will fetch me 8.0.1_3 even though I can see the formula should have 8.0.2 for macOS Sierra :/ ...

ilovezfs commented 7 years ago

The name is lying. 8.0.1_3 on Sierra is 8.0.2-rc1. ghc --version will show 8.0.1.20161117

Tehnix commented 7 years ago

@ilovezfs ah yeah, just figured when I was trying to manually download it. Thanks for the super quick response though! :)

alexanderkjeldaas commented 7 years ago

how does brew solve this issue? does stack use the homebrew distributions on os x?

ilovezfs commented 7 years ago

brew builds the Sierra bottle from the 8.0.2-rc1 source tarball. Before that was available, we used the head of the ghc-8.0 branch. That, combined with the most recent cabal, is sufficient to resolve the problem for GHC + cabal build. The bug is still unfixed for cabal new-build, though.

Note that a more conservative approach would be to backport the fix to 8.0.1: https://github.com/Homebrew/homebrew-core/pull/6416 (https://gist.githubusercontent.com/ilovezfs/c01cedf6dcf03d35d528e3aab244f42e/raw/1be2b95f935429553a132f0dbb7c2c25aea6c871/gistfile1.txt)

To my knowledge, stack hasn't backported the GHC fixes to their GHC binaries or made the changes to stack itself necessary to take advantage of the GHC and Cabal fixes.

stack will automatically get the GHC side of the equation once there's a stack 8.0.2 but additional changes will be needed to stack itself to actually fix the bug when using stack.

fizruk commented 7 years ago

@alexanderkjeldaas Note that Stack can use system GHC if that's available on PATH. See system-ghc option for stack.yaml.

That's what I use to fix my builds on Sierra now.

alexanderkjeldaas commented 7 years ago

@fizruk all well and good, but stack --system-ghc upgrade --git doesn't seem to work for example. so when stack is fixed, how do we upgrade?

fizruk commented 7 years ago

@alexanderkjeldaas what does stack upgrade --git do? If it simply clones stack repo, builds and then installs then I suspect you can just do that manually?

Note that if you don't need to upgrade to the Git version, you can install Stack with brew install haskell-stack. At least until the dust settles with GHC 8.0.2.

ilovezfs commented 7 years ago

By the way, brew can now build stack from source on Sierra, though stack itself cannot build stack yet. If nothing else, it's a neat parlor trick:

brew install --without-bootstrap haskell-stack
alexanderkjeldaas commented 7 years ago

Another issue: The new homebrew version will not compile the ghcjs releases from http://tolysz.org/ghcjs/untested/ .

Upgrading stack to a ghc version that doesn't build ghcjs is even worse for me than not being able to build large programs with the compiler shipping with stack.

ilovezfs commented 7 years ago

will not compile

meaning?

Are you sure you don't need to bump the ghc version constraint or something?

alexanderkjeldaas commented 7 years ago

With the released haddock:

    Preprocessing library haddock-api-2.17.3...
    [ 1 of 38] Compiling Paths_haddock_api (
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/autogen/Paths_haddock_api.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Paths_haddock_api.o )
    [ 2 of 38] Compiling Haddock.Version  ( src/Haddock/Version.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/Version.o )
    [ 3 of 38] Compiling Haddock.Syb      ( src/Haddock/Syb.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/Syb.o )
    [ 4 of 38] Compiling Haddock.Parser   ( src/Haddock/Parser.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/Parser.o )
    [ 5 of 38] Compiling Haddock.GhcUtils ( src/Haddock/GhcUtils.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/GhcUtils.o )

/private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/haddock-api-2.17.3/src/Haddock/GhcUtils.hs:20:1:
warning: [-Wunused-imports]
        The import of ‘Data.Function’ is redundant
          except perhaps to import instances from ‘Data.Function’
        To import instances alone, use: import Data.Function()

/private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/haddock-api-2.17.3/src/Haddock/GhcUtils.hs:27:1:
warning: [-Wunused-imports]
        The import of ‘RdrName’ is redundant
          except perhaps to import instances from ‘RdrName’
        To import instances alone, use: import RdrName()

/private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/haddock-api-2.17.3/src/Haddock/GhcUtils.hs:28:1:
warning: [-Wunused-imports]
        The import of ‘GhcMonad’ is redundant
          except perhaps to import instances from ‘GhcMonad’
        To import instances alone, use: import GhcMonad()

/private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/haddock-api-2.17.3/src/Haddock/GhcUtils.hs:30:1:
warning: [-Wunused-imports]
        The import of ‘UniqFM’ is redundant
          except perhaps to import instances from ‘UniqFM’
        To import instances alone, use: import UniqFM()
    [ 6 of 38] Compiling Haddock.Backends.Xhtml.Types (
src/Haddock/Backends/Xhtml/Types.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/Backends/Xhtml/Types.o
)
    [ 7 of 38] Compiling Haddock.Backends.Hyperlinker.Types (
src/Haddock/Backends/Hyperlinker/Types.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/Backends/Hyperlinker/Types.o
)
    [ 8 of 38] Compiling Haddock.Types    ( src/Haddock/Types.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/Types.o )

/private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/haddock-api-2.17.3/src/Haddock/Types.hs:451:10:
error:
        Duplicate instance declarations:
          instance NFData Name -- Defined at src/Haddock/Types.hs:451:10
          instance NFData Name -- Defined in ‘Name’

/private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/haddock-api-2.17.3/src/Haddock/Types.hs:452:10:
error:
        Duplicate instance declarations:
          instance NFData OccName -- Defined at src/Haddock/Types.hs:452:10
          instance NFData OccName -- Defined in ‘OccName’

/private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/haddock-api-2.17.3/src/Haddock/Types.hs:453:10:
error:
        Duplicate instance declarations:
          instance NFData ModuleName
            -- Defined at src/Haddock/Types.hs:453:10
          instance NFData ModuleName -- Defined in ‘Module’

With haddock HEAD

    [10 of 38] Compiling Haddock.Interface.LexParseRn (
src/Haddock/Interface/LexParseRn.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/Interface/LexParseRn.o
)

/Users/alekje/.stack/programs/x86_64-osx/x/ghcjs-0.2.1.9007010/.stack-work/downloaded/RdFf5gvtfQ84/haddock-api/src/Haddock/Interface/LexParseRn.hs:70:15:
error:
        • Couldn't match type
‘ghc-boot-th-8.0.1.20161117:GHC.LanguageExtensions.Type.Extension’
                         with ‘LangExt.Extension’
          NB: ‘LangExt.Extension’
                is defined in ‘GHC.LanguageExtensions.Type’
                    in package ‘ghc-boot-th-8.0.1’

‘ghc-boot-th-8.0.1.20161117:GHC.LanguageExtensions.Type.Extension’
                is defined in ‘GHC.LanguageExtensions.Type’
                    in package ‘ghc-boot-th-8.0.1.20161117’
          Expected type: [LangExt.Extension]
            Actual type:
[ghc-boot-th-8.0.1.20161117:GHC.LanguageExtensions.Type.Extension]
        • In the expression:
            map toEnum (toList $ extensionFlags dflags)
            \\ languageExtensions (language dflags)
          In an equation for ‘flags’:
              flags
                = map toEnum (toList $ extensionFlags dflags)
                  \\ languageExtensions (language dflags)
          In the expression:
            do { (hmi, doc) <- case mayStr of {
                                 Nothing -> return failure
                                 Just (L _ (HsDocString fs)) -> do { ... }
};
                 let flags :: [LangExt.Extension]
                     flags
                       = map toEnum (toList $ extensionFlags dflags)
                         \\ languageExtensions (language dflags);
                 return
                   (hmi
                      {hmi_safety = Just $ showPpr dflags safety,
                       hmi_language = language dflags, hmi_extensions =
flags},
                    doc) }

On Sun, Nov 27, 2016 at 9:02 PM, ilovezfs notifications@github.com wrote:

will not compile

meaning?

Are you sure you don't need to bump the ghc version constraint or something?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/commercialhaskell/stack/issues/2577#issuecomment-263143765, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUtqQ85OW3Ea78JF9ah8s6BST73YAroks5rCeHngaJpZM4J546w .

alexanderkjeldaas commented 7 years ago

This is based on http://tolysz.org/ghcjs/untested/ghc-8.0-2016-11-27-lts-7.10-9007010.tar.gz

The second try with these changes to stack.yaml:

...
packages:
- location: .
- location:
    git:    https://github.com/haskell/haddock.git
    commit: 240bc38b94ed2d0af27333b23392d03eeb615e82
  subdirs:
  - haddock-api

extra-deps:
- haddock-api-2.17.3

On Mon, Nov 28, 2016 at 7:39 AM, Alexander Kjeldaas ak@formalprivacy.com wrote:

With the released haddock:

    Preprocessing library haddock-api-2.17.3...
    [ 1 of 38] Compiling Paths_haddock_api ( .stack-work/dist/x86_64-osx/
Cabal-1.24.1.0/build/autogen/Paths_haddock_api.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Paths_haddock_api.o )
    [ 2 of 38] Compiling Haddock.Version  ( src/Haddock/Version.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/Version.o )
    [ 3 of 38] Compiling Haddock.Syb      ( src/Haddock/Syb.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/Syb.o )
    [ 4 of 38] Compiling Haddock.Parser   ( src/Haddock/Parser.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/Parser.o )
    [ 5 of 38] Compiling Haddock.GhcUtils ( src/Haddock/GhcUtils.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/GhcUtils.o )

    /private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/
haddock-api-2.17.3/src/Haddock/GhcUtils.hs:20:1: warning:
[-Wunused-imports]
        The import of ‘Data.Function’ is redundant
          except perhaps to import instances from ‘Data.Function’
        To import instances alone, use: import Data.Function()

    /private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/
haddock-api-2.17.3/src/Haddock/GhcUtils.hs:27:1: warning:
[-Wunused-imports]
        The import of ‘RdrName’ is redundant
          except perhaps to import instances from ‘RdrName’
        To import instances alone, use: import RdrName()

    /private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/
haddock-api-2.17.3/src/Haddock/GhcUtils.hs:28:1: warning:
[-Wunused-imports]
        The import of ‘GhcMonad’ is redundant
          except perhaps to import instances from ‘GhcMonad’
        To import instances alone, use: import GhcMonad()

    /private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/
haddock-api-2.17.3/src/Haddock/GhcUtils.hs:30:1: warning:
[-Wunused-imports]
        The import of ‘UniqFM’ is redundant
          except perhaps to import instances from ‘UniqFM’
        To import instances alone, use: import UniqFM()
    [ 6 of 38] Compiling Haddock.Backends.Xhtml.Types (
src/Haddock/Backends/Xhtml/Types.hs, .stack-work/dist/x86_64-osx/
Cabal-1.24.1.0/build/Haddock/Backends/Xhtml/Types.o )
    [ 7 of 38] Compiling Haddock.Backends.Hyperlinker.Types (
src/Haddock/Backends/Hyperlinker/Types.hs, .stack-work/dist/x86_64-osx/
Cabal-1.24.1.0/build/Haddock/Backends/Hyperlinker/Types.o )
    [ 8 of 38] Compiling Haddock.Types    ( src/Haddock/Types.hs,
.stack-work/dist/x86_64-osx/Cabal-1.24.1.0/build/Haddock/Types.o )

    /private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/
haddock-api-2.17.3/src/Haddock/Types.hs:451:10: error:
        Duplicate instance declarations:
          instance NFData Name -- Defined at src/Haddock/Types.hs:451:10
          instance NFData Name -- Defined in ‘Name’

    /private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/
haddock-api-2.17.3/src/Haddock/Types.hs:452:10: error:
        Duplicate instance declarations:
          instance NFData OccName -- Defined at src/Haddock/Types.hs:452:10
          instance NFData OccName -- Defined in ‘OccName’

    /private/var/folders/pq/xz5t60ld4v10j_tt7bd25rfhtzqwq8/T/stack51151/
haddock-api-2.17.3/src/Haddock/Types.hs:453:10: error:
        Duplicate instance declarations:
          instance NFData ModuleName
            -- Defined at src/Haddock/Types.hs:453:10
          instance NFData ModuleName -- Defined in ‘Module’

With haddock HEAD

    [10 of 38] Compiling Haddock.Interface.LexParseRn (
src/Haddock/Interface/LexParseRn.hs, .stack-work/dist/x86_64-osx/
Cabal-1.24.1.0/build/Haddock/Interface/LexParseRn.o )

    /Users/alekje/.stack/programs/x86_64-osx/x/ghcjs-0.2.1.
9007010/.stack-work/downloaded/RdFf5gvtfQ84/haddock-api/src/Haddock/Interface/LexParseRn.hs:70:15:
error:
        • Couldn't match type ‘ghc-boot-th-8.0.1.20161117:
GHC.LanguageExtensions.Type.Extension’
                         with ‘LangExt.Extension’
          NB: ‘LangExt.Extension’
                is defined in ‘GHC.LanguageExtensions.Type’
                    in package ‘ghc-boot-th-8.0.1’
              ‘ghc-boot-th-8.0.1.20161117:GHC.LanguageExtensions.Type.
Extension’
                is defined in ‘GHC.LanguageExtensions.Type’
                    in package ‘ghc-boot-th-8.0.1.20161117’
          Expected type: [LangExt.Extension]
            Actual type: [ghc-boot-th-8.0.1.20161117:
GHC.LanguageExtensions.Type.Extension]
        • In the expression:
            map toEnum (toList $ extensionFlags dflags)
            \\ languageExtensions (language dflags)
          In an equation for ‘flags’:
              flags
                = map toEnum (toList $ extensionFlags dflags)
                  \\ languageExtensions (language dflags)
          In the expression:
            do { (hmi, doc) <- case mayStr of {
                                 Nothing -> return failure
                                 Just (L _ (HsDocString fs)) -> do { ...
} };
                 let flags :: [LangExt.Extension]
                     flags
                       = map toEnum (toList $ extensionFlags dflags)
                         \\ languageExtensions (language dflags);
                 return
                   (hmi
                      {hmi_safety = Just $ showPpr dflags safety,
                       hmi_language = language dflags, hmi_extensions =
flags},
                    doc) }

On Sun, Nov 27, 2016 at 9:02 PM, ilovezfs notifications@github.com wrote:

will not compile

meaning?

Are you sure you don't need to bump the ghc version constraint or something?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/commercialhaskell/stack/issues/2577#issuecomment-263143765, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUtqQ85OW3Ea78JF9ah8s6BST73YAroks5rCeHngaJpZM4J546w .

hatashiro commented 7 years ago

For someone looking for TL;DR:

  1. This is because macOS Sierra has changed something internal.
  2. This will be fixed in GHC 8.0.2, which is in RC. Which means it will be fixed in Stack when a next resolver using GHC 8.0.2 is released. Current Stack resolvers use GHC 8.0.1.
  3. brew install ghc will install GHC 8.0.2 RC. (it shows 8.0.1 when ghc --version though)
  4. We can force Stack to use the ghc installed by brew with stack --system-ghc.
    For example: 
    $ brew install ghc
$ stack --system-ghc build

I have just tried and saw the problem solved. Please correct me if anything is wrong.

fizruk commented 7 years ago

It appears that you can also use GHC 8.0.2-rc1 directly with Stack (no brew needed) with a stack.yaml like this one. Basically you just tell Stack where to get GHC 8.0.2-rc1 for every OS you need. I'll copy the contents here (note that ghc-8.0.1.20161117 is what GHC 8.0.2-rc1 is called):

compiler-check: match-exact
resolver: lts-7.10
compiler: ghc-8.0.1.20161117
setup-info:
  ghc:
    linux64:
      8.0.1.20161117:
        url: http://downloads.haskell.org/~ghc/8.0.2-rc1/ghc-8.0.1.20161117-x86_64-deb8-linux.tar.xz
        content-length: 112047972
        sha1: 6a6e4c9c53c71cc84b6966a9f61948542fd2f15a
    macosx:
      8.0.1.20161117:
        url: https://downloads.haskell.org/~ghc/8.0.2-rc1/ghc-8.0.1.20161117-x86_64-apple-darwin.tar.xz
        content-length: 113379688
        sha1: 53ed03d986a49ea680c291540ce44ce469514d7c
    windows64:
      8.0.1.20161117:
        url: https://downloads.haskell.org/~ghc/8.0.2-rc1/ghc-8.0.1.20161117-x86_64-unknown-mingw32.tar.xz
        content-length: 155652048
        sha1: 74118dd8fd8b5e4c69b25df1644273fbe13177c7
tolysz commented 7 years ago

@alexanderkjeldaas It is an interesting find. But once the lts moves to ghc 8.0.2 all packages will be compiling together. Thus this issue will go away. For now, you would need to find versions which work and you could create a new ghcjs bundle.

chrisdone commented 7 years ago

Now that GHC 8.0.2 is out, can anyone confirm that this fixes the problem? I'm still on old OS X, but I have clients who are on Sierra.

lorenzo commented 7 years ago

I can confirm this fixes the problem

fizruk commented 7 years ago

Fixed problem for me as well.

bitemyapp commented 7 years ago

Seems alright here, modulo abandoning 7.8 and 7.10 on my Mac.

chrisdone commented 7 years ago

http://www.memegasms.com/media/created/vhyfxm.jpg

ddacunha commented 7 years ago

Can something be done to speed up compatibility with latest OS releases? Six months after official release (not counting OS public beta) feels on the long side.

bitemyapp commented 7 years ago

@ddacunha take it to the GHC team

vertexcite commented 7 years ago

Should the comment on the install doc be updated? https://docs.haskellstack.org/en/stable/install_and_upgrade/#mac-os-x says "macOS Sierra warning: There are new limitations in the dynamic linker that are causing problems for GHC when building projects with many dependencies. See #2577 for more information."

borsboom commented 7 years ago

@vertexcite It could be updated to mention that this is fixed in GHC 8.0.2/LTS 8. A PR would be welcome!

vertexcite commented 7 years ago

@borsboom PR #3016

jasonstolaruk commented 7 years ago

I'm still seeing this issue on macOS Sierra 10.12.3. In my .stack/global-project/stack.yaml, I set the resolver to lts-8.5. Then I ran stack upgrade in my home directory and I got:

[ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.3 for x86_64-apple-darwin):
        Loading temp shared object failed: dlopen(/var/folders/cg/wclcdwbs4cd9qppgccbc5rwh0000gn/T/ghc94925_0/libghc_68.dylib, 5): no suitable image found.  Did find:
        /var/folders/cg/wclcdwbs4cd9qppgccbc5rwh0000gn/T/ghc94925_0/libghc_68.dylib: malformed mach-o: load commands size (50712) > 32768

In the error message I see "GHC version 7.10.3", which is really odd. If I run stack path | grep ghc I only see references to 8.0.2, and nothing about 7.10.3.

Anyone know what the problem might be?