On 2017-04-10 04:58 PM, Lana Black wrote:
~/devel/hs/cabal-bug> cabal build Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Resolving dependencies... Configuring cabal-bug-0.1...
I am surprised that at this point you did not receive the warning I received: Warning: Instead of 'ghc-options: -lHSrts-ghc8.0.2' use 'extra-libraries: HSrts-ghc8.0.2' In my http://www.vex.net/~trebla/haskell/so.xhtml I use the extra-libraries route (and build-type: Configure to automate "8.0.2"). Also I do not use ghc-options, see below.
Building cabal-bug-0.1... Preprocessing library cabal-bug-0.1... [1 of 1] Compiling Cabal.Bug ( src/Cabal/Bug.hs, dist/build/Cabal/Bug.o ) Linking a.out ...
This a.out is not an executable. It is a shared library. The name "a.out" is a historical generic bland default name for any linker output whenever the user fails to specify "-o realname". Linker output could be executable or library depending on other flags. Now to see why this a.out exists at all, you really should use "cabal build -v" to see how cabal uses GHC. But the short story is: cabal calls GHC at least 3 times: 1st time is to compile *.hs files to *.o files, e.g., Bug.hs to Bug.o. (If you have multiple *.hs files, it is still one call, and you also see a -j2 or -j4 or -j65536 according to your number of CPU cores to tell GHC to parallelize.) 2nd time is to produce the *.a library. 3rd time is to produce the *.so library. Now, if you hardcode the blunt sledgehammer that is ghc-options: -fPIC -dynamic -shared, as opposed to letting cabal do it at the right times (namely, -shared during the 3rd time only), then the extraneous -shared during the 1st time, which is supposed to be *.o only, tricks GHC into calling the linker to produce an extraneous *.so (except there is no -o so the name comes out as a.out). But do not think that you can declare victory now and take this a.out and get away with it. For all practical purposes you will need to include some C code in the library. See again my article for why. But the short story is: Who's gonna call hs_init? The 1st call to GHC does not mention the C code whatsoever. The a.out thus produced will be missing the C code. It is incomplete. There are extra calls after the 1st and before the 2nd to compile *.c to *.o. Only by the 3rd call are all *.o files, from both Haskell and C, brought together into a complete *.so. (Well, the 2nd call too, but you are not going after the *.a.)