Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not compile with profiling enabled on OSX or Ubuntu #147

Closed
ababkin opened this issue May 6, 2015 · 10 comments
Closed

Does not compile with profiling enabled on OSX or Ubuntu #147

ababkin opened this issue May 6, 2015 · 10 comments

Comments

@ababkin
Copy link

ababkin commented May 6, 2015

Previously reported same issue on OSX (#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
Copy link
Member

@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
Copy link
Author

ababkin commented May 6, 2015

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
Copy link
Member

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
Copy link
Author

ababkin commented May 6, 2015

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

@gregorycollins
Copy link
Member

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
Copy link
Contributor

@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
Copy link
Member

@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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Member

Fixed! We had to tell cabal about the TemplateHaskell.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants