GHC skips recompilation of a module if the module code hasn't changed, even if the flags in use *have* changed. A benign version is that switching on -O won't recompile modules that were compiled without -O. But here's a nastier version: changing the -main-is flag can lead to an obscure link error. Details below supplied by Niels [cpjvelde@cs.uu.nl]SimonActually, i reproduced it now and the reason is a bit different. I have anapplication Test and Test2. They both have a main function. Test imports Test2for some other function. So this is how those files look like:~/pancake > cat Test.hsmodule Test whereimport Test2 hiding (main)main = doit~/pancake > cat Test2.hsmodule Test2 wheredoit = print "Test2.doit"main = print "Test2.main"I then first compile the first app:~/pancake > ghc --make -main-is Test.main Test.hsChasing modules from: Test.hsCompiling Test2 ( ./Test2.hs, ./Test2.o )Compiling Test ( Test.hs, Test.o )Linking ...then i compile the second app:~/pancake > ghc --make -main-is Test2.main Test2.hsChasing modules from: Test2.hsSkipping Test2 ( Test2.hs, Test2.o )Linking .../usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function `main':: undefined reference to `__stginit_ZCMain'/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0x28): In function `main':: undefined reference to `ZCMain_main_closure'collect2: ld returned 1 exit statusSo I guess generating Test2.o the first time and using -main-is renamed the mainin Test2.o . Since it is not recompiled when I want to compile the second app,it fails because it cant find the main...I thought providing a -main-is flagagain when compiling the second app would somehow force recompilation of Test2.oor at least fixing the 'renaming' that the first compilation of Test2.o had caused.greetings, Niels.