stack build --executable-profiling not working

[bitemyapp]

$ which ghc
/Users/callen/.stack/programs/x86_64-osx/ghc-7.8.4/bin/ghc

$ stack --version
Version 0.1.2.1, Git revision 2723b3567e44725b176c35786a5e11db454d183e

    src/Snap/Starter.hs:1:1:
        cannot find normal object file ‘.stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/snap/snap-tmp/Snap/StarterTH.dyn_o’
        while linking an interpreted expression

      /Users/callen/.stack/programs/x86_64-osx/ghc-7.8.4/bin/runhaskell -package=Cabal-1.18.1.5 -clear-package-db -global-package-db -package-db=/Users/callen/.stack/snapshots/x86_64-osx/lts-2.16/7.8.4/pkgdb/ /var/folders/yr/p4z975f13jbdvwhbgs7gv2j40000gn/T/stack76300/Setup.hs --builddir=.stack-work/dist/x86_64-osx/Cabal-1.18.1.5/ build --ghc-options -hpcdir .stack-work/dist/x86_64-osx/Cabal-1.18.1.5/hpc/.hpc/
    Process exited with code: ExitFailure 1
    Logs have been written to: "/Users/callen/work/gordium/adserver/.stack-work/logs/muttonchops-0.1.2.4.log"

    2 warnings generated.
    In-place registering muttonchops-0.1.2.4...
    Preprocessing executable 'muttonchops-test' for muttonchops-0.1.2.4...
    Linking .stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/muttonchops-test/muttonchops-test ...
    ld: library not found for -lHSrts_debug_p
    clang: error: linker command failed with exit code 1 (use -v to see invocation)

Like to have stacktraces in our error notifications, currently attempts to build with executable profiling alone or also with library profiling fail.

The error is a little cryptic, does this mean the GHC stack setup fetches isn't built for profiling? If so, I think that's an unfortunate default.

[mgsloan]

This is a strange issue, does this work fine with cabal install? I wonder what it could be doing differently.

This error message is familiar, Chris Done also encountered it, but in the context of test --coverage - #222 (comment) . Very curious! I just realized that --enable-library-profiling / --enable-executable-profiling isn't needed for test coverage, so I'm going to remove that, to avoid such issues. We definitely ought to support profiling, though.

[jkarni]

The bug is mentioned in the Snap FAQ, though it's not evident how to port their cabal workaround to stack. The bug mentioned in the FAQ seems to be #8180

[mgsloan]

Yeah, it seems to be very similar to that bug. Maybe despite being closed as fixed in 7.8, some form still persists?

It'd be hacky, but we could try to detect this circumstance and suggest the workaround. Yuck!

[snoyberg]

Is there any reasonable way we can resolve this? It doesn't seem like there is. I'd recommend closing as wontfix and adding a comment to the FAQ.

[borsboom]

Is there a workaround for this in stack that can be documented in the FAQ?

[bitemyapp]

@borsboom I never figured one out and had to give up due to time constraints. We'll probably have to move to 7.10.2 for the CallStack implicit argument to get what we want from this due to Snap's misbehavior here.