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. Because this change affects linking it is possibly system dependent so once the tests are resolved it'll need checking on other platforms and the bindists will need checking too (just to make sure the Main.o is getting included and installed etc). I'm getting three validate test failures at the moment. The patch causes two of the test failures. Now whether we think the tests are wrong or we think I've broken things is somewhat a matter of opinion and one I'd like to check with people. It depends on exactly what we thing -no-hs-main means and when it is required. Is it required every time we link a final binary that supplies its own definition of main? The user guide says: 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 not convinced the first part of the description is true. The only place in ghc where I see -no-hs-main have any affect is to force linking as described in the last paragraph. For example, should I have to use -no-hs-main for a pure C program? $ ghc -o hello hello.c (note this does link against the rts which does contains main) Currently this works on ELF platforms because of the way the static linker handles duplicate symbols in static libs, but with my patch we get duplicate symbol errors. If we think this use case is important then it's probably possible to arrange to use a libHSrtsmain.a containing Main.o which means the linker will ignore the duplicate main symbol. (Note that we would always use a static libHSrtsmain.a, even if we were using a shared libHSrts.so). I've not checked PE and Mach-O platforms. Note that this patch fixes test ffi002 with way=dyn. That test uses a C main function, which highlighted the problem with main being in the rts when using shared libs. With the patch, if someone does use a C main and forgets -no-hs-main then the failure mode will be like this: /home/duncan/prgs/ghc/ghc-head-hacking/rts/dist/build/Main.o: In function `main': Main.c:(.text+0x0): multiple definition of `main' testblockalloc.o:testblockalloc.c:(.text+0x0): first defined here /home/duncan/prgs/ghc/ghc-head-hacking/rts/dist/build/Main.o: In function `main': Main.c:(.text+0x17): undefined reference to `ZCMain_main_closure' Main.c:(.text+0x1c): undefined reference to `__stginit_ZCMain' collect2: ld returned 1 exit status It's testblockalloc and testwsdeque which will need fixing if we go with this approach. On reflection, I expect we'll have to go with the libHSrtsmain.a scheme rather than my current patch, because people do use ghc as a C compiler. It does look like -no-hs-main is redundant. ------ I'm also getting a failure in CPUTime001 for just optasm. The other ways work. It looks like: Actual stdout output differs from expected: --- ./lib/CPUTime/CPUTime001.stdout.normalised 2009-05-14 22:48:03.000000000 +0100 +++ ./lib/CPUTime/CPUTime001.run.stdout.normalised 2009-05-14 22:48:03.000000000 +0100 @@ -1,4 +1,4 @@ 1028457 1664079 2692537 -(True,True) +(False,True) *** unexpected failure for CPUTime001(optasm) Is anyone else getting this? I'll re-run without my changes but I doubt it'd cause this kind of failure. Duncan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
