On Fri, 2009-05-15 at 00:03 +0100, Duncan Coutts wrote: > On Wed, 2009-05-13 at 23:24 +0000, Duncan Coutts wrote: > > > So I propose that we do not keep 'main' in the rts library. Instead we > > should keep Main.o as a separate .o file that sits along side the > > installed rts library and whenever we use a Haskell main, then we just > > link in Main.o. Obviously when we link using -no-hs-main then we don't. > > http://haskell.org/~duncan/ghc/external-main.dpatch > > Here's a patch for review which implements this scheme. Also included is > a related patch to remove an older windows-only version of the same > scheme. Also a simple makefile fix for the --enable-shared case.
New updated patches: http://haskell.org/~duncan/ghc/external-main2a.dpatch.bz2 http://haskell.org/~duncan/ghc/external-main2b.dpatch.bz2 These replace the previous patch set rather than being cumulative. The first is for ghc HEAD and the second for Cabal HEAD. This updated patch eliminates the drawback of the first patch so that there should be little user-observable change in ghc's linking behaviour. I've also included a bunch of shared libs patches. I'm preparing a blog post to give a status update on what now works. These patches pass validate on x86-64 (except for T1969 which apparently is known to be flaky). Since the changes affects linking, which tends to be rather platform dependent, we should validate the patches on Windows and OSX too. > http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-linker > > -no-hs-main > > In the event you want to include ghc-compiled code as part of > another (non-Haskell) program, the RTS will not be supplying its > definition of main() at link-time, you will have to. To signal > that to the compiler when linking, use -no-hs-main. > > [snip] > > The -no-hs-main flag can also be used to persuade the compiler > to do the link step in --make mode when there is no Haskell Main > module present (normally the compiler will not attempt linking > when there is no Main). I'm convinced that the docs are currently wrong here and the only effect of -no-hs-main is the one given in the final paragraph. With the new patch the first part will become true, though there is still no need to specify -no-hs-main because of the way the static linker handles duplicate symbols. Here's an alternative (which only applies with the patches): Normally, GHC provides a main(), which arranges to invoke Main.main in the Haskell program. In the event you want to include ghc-compiled code as part of another (non-Haskell) program then you may want to supply your own definition of main() at link-time. See also Section 8.2.1.1, “Using your own main()”. The -no-hs-main flag instructs GHC not to supply any definition of main(). This flag is rarely needed because any object files or libraries containing main() that you supply should take precedence over the main() provided by GHC. Additionally, in --make mode the -no-hs-main flag forces the compiler to do the link step when there is no Haskell Main module present. Normally the compiler will not attempt linking when there is no Main, but if you are supplying your own main() then you will want to do the link step. Notice that since the command-line passed to the linker is rather involved, you probably want to use ghc to do the final link of your `mixed-language' application. This is not a requirement though, just try linking once with -v on to see what options the driver passes through to the linker. Duncan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
