Cabal: -prof GHC flag should not to be used with --ghc-options cabal flag

[robstewart57]

When a user wants to run with cost modelling profiling enabled, they need to use +RTS -p. For this to work and when invoking GHC directly, the user types:

$ ghc -prof -fprof-auto -rtsopts Main.hs

However, if they are using cabal, they should type:

$ cabal install --enable-executable-profiling --enable-library-profiling --ghc-options="-fprof-auto -rtsopts"

It might not be clear that when cabal is used to invoke GHC, -prof should not be used in --ghc-options. If it is included, then they are likely to see compiler error messages relating to p_dyn, e.g.

Failed to load interface for ‘GHC.Integer.Type’
Perhaps you haven't installed the "p_dyn" libraries for package ‘integer-gmp-1.0.0.0’?
Use -v to see a list of the files searched for.

I initially raised this as a GHC documentation bug, but there it has been suggested that instead, cabal should throw an error or at least print a warning that -prof should not appear in the string passed to --ghc-options.

This is the GHC ticket, that I'd like to close once the corresponding stack and cabal tickets are discussed: https://ghc.haskell.org/trac/ghc/ticket/10894

This is the mirrored stack ticket: https://github.com/commercialhaskell/stack/issues/1015

[ttuegel]

Actually, with the latest Cabal, they should probably only do

$ cabal install --enable-profiling --ghc-options="-fprof-auto -rtsopts"

and with the latest development version, they should only do

$ cabal install --enable-profiling --ghc-options="-rtsopts"

but these may be inadequately documented and it surely should be an error to include -prof in --ghc-options.

[robstewart57]

@ttuegel is that to say: that in the development version, when --enable-profiling is enabled then the -fprof-auto flag is automatically passed to GHC ?

[ttuegel]

@robstewart57 Well, not quite: we actually use -fprof-auto-exported for libraries and -fprof-auto-top for executables. In practice, -fprof-auto isn't usually what you want; it annotates everything, to the point that the cost of profiling begins to dominate the costs you are trying to profile. In case you _really_ want -fprof-auto, it should be safe to add it to --ghc-options.

[ezyang]

I think Cabal strips out some --ghc-options currently? (Or this may be for things in the Cabal file). In that case, I'd suggest detecting -prof in the options and acting as if it was --enable-profiling.

[YPares]

But if you remove -prof from GHC options at building, how can you pass +RTS -p at execution?
It doesn't work, I tried it and the RTS complains.

[ttuegel]

@YPares Cabal gives -prof whenever you configure with --enable-profiling. @ezyang is suggesting that we forbid users from doing --ghc-options="-prof", which doesn't work right anyway.

[robstewart57]

@ttuegel And leading on from the mirrored stack github ticket about the same issue, stack commit https://github.com/commercialhaskell/stack/commit/7f49966cc1b708ab1d35495e79b5c78d12ed4ed2 now means that when the misuse of cabal-install that @ezyang is describing, i.e. --ghc-options="-prof" is passed to stack, the user now sees the following error message:

$ stack install --ghc-options="-prof"
When building with stack, you should not use the -prof GHC option
Instead, please use --enable-library-profiling and --enable-executable-profiling
See: https://github.com/commercialhaskell/stack/issues/1015
-prof GHC option submitted

[YPares]

Ok, indeed it does, but it's weird.
When I run "cabal run +RTS -p", I get:

cabal: the flag -p requires the program to be built with -prof
cabal: 
cabal: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args>
cabal:

But when I manually find the executable and run it ("./dist/build/my-exe/my-exe +RTS -p") then it works. I thought both were the same?

[ttuegel]

@YPares You are passing +RTS -p to cabal. You want to do cabal run -- +RTS -p instead.

[YPares]

@ttuegel Ok... now I feel stupid. Thanks a lot ^^. Is it possible to have cabal issue a warning when given +RTS options? Like "BEWARE. This is (maybe) not the RTS you are looking for"?

[Anton-Latukha]

Would add to this old thread.

I found this thread by:

cabal: the flag -hb requires the program to be built with -prof

and

Perhaps you haven't installed the "p_dyn" libraries for package ‘integer-gmp’?

I try to profile HNix inside nix-shell, using current v2-*options*, since those integrate with Nix.

I tried many variants:
1) Now using:
fish cabal v2-build --enable-tests --enable-profiling --ghc-options="-rtsopts" +RTS -p

I enabled profiling the right way, as you several times restated in this thread. But I get the same:

cabal: the flag -p requires the program to be built with -prof

But I already enabled profiling the right way.

2) And if I, as cabal asks, add -prof - I do the wrong thing, as you also restated above several times, and then I get the head topic of the thread:

/nix/store/3gahzbx1zk54wlnrnpw8wdbcbdrzxqhd-ghc-8.6.5/lib/ghc-8.6.5/template-hsc.h:91: note: this is the location of the previous definition
91 | #define hsc_alignment(x...)
|
Building library for terminal-size-0.3.2.1..
[1 of 3] Compiling System.Console.Terminal.Common ( src/System/Console/Terminal/Common.hs, dist/build/System/Console/Terminal/Common.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.5 for x86_64-unknown-linux):
lookupGlobal
Failed to load interface for ‘GHC.Integer.Type’
Perhaps you haven't installed the "p_dyn" libraries for package ‘integer-gmp’?
Use -v to see a list of the files searched for.
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/typecheck/TcEnv.hs:132:32 in ghc:TcEnv

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

3) If I give +RTS -p not to cabal, but to executable - I got the same thing anyway.

hnix: the flag -p requires the program to be built with -prof

You, see - every variant that I was recommended to use, found or tried - results into the option configuration conflict. I am in the complete double bind.