Does not compile with profiling enabled on OSX or Ubuntu

[ababkin]

Previously reported same issue on OSX (https://github.com/snapframework/snap/issues/146). Suspecting it's OSX related, tried to spin up an AWS box with Ubuntu 14.04 LTS and compile with profiling enabled. Also used newest released versions of GHC and cabal to overrule any particular version. Getting the same exact error as in the previous issue i logged (link above).

Below i'm providing detailed steps to reproduce this. Please don't close this issue prematurely, it really does look like a problem with snap.

Steps to reproduce:

• spin up an AWS box with Ubuntu 14.04 LTS AMI
• run following commands: sudo apt-get update sudo apt-get install libssl-dev git libghc-zlib-dev sudo apt-get install software-properties-common # v12.10 and above sudo add-apt-repository -y ppa:hvr/ghc sudo apt-get update sudo apt-get install cabal-install-1.22 ghc-7.10.1-prof happy-1.19.5 alex-3.1.4
• add to PATH: (~/.profile) export PATH=~/.cabal/bin:/opt/cabal/1.22/bin:/opt/ghc/7.10.1/bin:/opt/happy/1.19.5/bin:/opt/alex/3.1.4/bin:$PATH
• reload terminal
• run: git clone https://github.com/snapframework/snap.git cd snap/ git checkout 0.14-stable cabal sandbox init vim cabal.sandbox.config
• add the following to cabal.sandbox.config: library-profiling: True executable-profiling: True
• run: cabal update cabal configure --enable-library-profiling --enable-profiling cabal install --enable-library-profiling --enable-profiling

results in error:

src/Snap/Starter.hs:1:1: cannot find normal object file ‘dist/dist-sandbox-3244e308/build/snap/snap-tmp/Snap/StarterTH.dyn_o’ while linking an interpreted expression cabal: Error: some packages failed to install: snap-0.14.0.2 failed during the building phase. The exception was: ExitFailure 1

[mightybyte]

@ababkin The first-order solution here is to not enable executable profiling. The executable in question here is the "snap" executable. The only thing that does is create project templates--i.e. not something that you need profiling for. It builds fine when executable profiling is not turned on. You usually don't want that enabled by default anyway.

Now I'll agree that this is something that should work, and therefore it is definitely a bug. But the existence of this simple workaround makes it pretty minor in the grand scheme of things. But thanks for the detailed report. It's much appreciated.

[ababkin]

Appreciate it @mightybyte, this workaround worked.

for others' sake, here is what i did:

• cd into my project that depends on snap>
• put only "library-profiling: True" into cabal.config
• $ cabal configure --enable-library-profiling
• $ cabal install --enable-library-profiling --dependencies-only
• add only "executable-profiling: True" into cabal.config
• $ cabal configure --enable-library-profiling --enable-executable-profiling
• $ cabal install --enable-library-profiling --enable-executable-profiling

... and profit!

[mightybyte]

Just to clarify...

@ababkin I believe I've heard people say that the best practice is to set library-profiling to true in your config file (like you did), but not executable-profiling. This makes it so that you do not need to specify it on the command line. Then whenever you want executable profiling, just put it on the cabal command line. You don't need to add it to cabal.config. So I would recommend skipping your second bullet point and just build with cabal install --enable-executable-profiling.

[ababkin]

Thanks again, i had a feeling i was doing things redundantly.

[gregorycollins]

Can you confirm that it's possible to do executable profiling on your executable that depends on snap? Or are you hitting the same bug there?

[MichaelXavier]

@gregorycollins thought I'd chime in here with my case as its relevant to your question. I am trying to use executable profiling to profile my own executable which depends on 2 libraries that are subject to this issue (snap, and jmacro which I depend on indirectly). I don't need my dependencies' executables but as it stands (using stack), supplying --enable-executable-profiling applies to all dependencies no matter what. If I install all of my dependencies with just --enable-library-profiling and then try to build with --enable-executable-profiling, all of my dependencies will be rebuilt because of the flag change and jmacro and snap will fail to compile, thereby making it not possible to compile my executable with profiling.

[mightybyte]

@MichaelXavier I just took a look at this, but I'm not seeing a way forward here. It almost seems like a cabal/ghc bug. The StarterTH module is listed in the other-modules section. It builds fine normally. Taking it out of other-modules causes a linker error. Moving the StarterTH module into Starter isn't possible because of the stage restriction. I don't know what other options are available to me. Suggestions?

[MichaelXavier]

@mightybyte I'm a bit out of my depth on this one. Maybe there isn't anything that can be done. I've got my eye on this issue on stack which would stop applying executable-profiling to dependencies. This wouldn't really fix anything but it does speak to your point that very rarely does the user actually want executable profiling on their dependencies. Usually if they wanted to profile dependency executables they would clone the repo of that dependency and profile it directly.

If it is a compiler bug or cabal bug (assuming cabal-the-library since it affects stack too), maybe we could get a repro case and create a GHC bug ticket.

[MichaelXavier]

At least as far as stack goes, the current master on stack has a fix that makes this a non-issue for stack users where dependencies are not built with executable profiling, only the direct project executable.

[mightybyte]

Fixed! We had to tell cabal about the TemplateHaskell.