Hello glasgow-haskell-users, i've put my hands on the ghc 6.6/mingw32 dated 1st september (http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-m...) overall, compilation of my 5 kloc application was fine. on the 6.2->6.4 transition, i was bitten by two API changes, but this time all APIs and language features i used remains stable. it's great! the most funny part was that parallel arrays are still work :))) nevertheless, i've captured several minor problems: 1. ghc +RTS -A10m aborts with the message: ghc.exe: getMBlocks: VirtualAlloc MEM_COMMIT failed: The parameter is incorrect. although i guess that it was already fixed since 1st September. btw, how about adding using various RTS switches to ghc as test cases? GHC is very large program and any problems with RTS flags would be captured in this way 2. ghc compilation don't includes directory where Rts.h, Stg.h and similar files resides, "$(GHC)\lib\i386-unknown-mingw32\include" on my installation. it results in failing of via-C compilation, compilation of *stub.c files, and inclusion of "Typeable.h". i was going around this problem by using -I switch. it's possible that it's just packaging problem. again - isn't it possible to catch this problem by testsuite? imho, that this error was not catched means that windows version isn't really tested by anyone? how about trying to build various packages on mingw32 version as test before releasing 6.6? 3. ghc 6.6 includes smart relinking capability which don't relink exe file if it already exists and .hs source files was not changed. that's great but ignores other .o files that can be also linked to program, for example those that was compiled from C sources: gcc -c -o a.o a.c ghc --make Main.hs a.o this command incorrectly don't relinks executable if a.c was changed but Main.hs wasn't -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Tue, Sep 19, 2006 at 02:33:46PM +0400, Bulat Ziganshin wrote:
3. ghc 6.6 includes smart relinking capability which don't relink exe file if it already exists and .hs source files was not changed. that's great but ignores other .o files that can be also linked to program, for example those that was compiled from C sources:
gcc -c -o a.o a.c ghc --make Main.hs a.o
this command incorrectly don't relinks executable if a.c was changed but Main.hs wasn't
The is another similar problem. Let's say I have an up-to-date compiled program and I want to recompile it with profiling turned on. In older ghc version adding -prof option caused all modules to be recompiled and the whole application relinked. Now I have to manually delete the application binary to force recompilation or use -fno-recomp. BTW. The -fno-recomp option has a very unintuitive name, at least for me. When I see "-fno-recomp", my brain thinks "no recompilation", meaning "no unneccesary recompilation", which is what --make does by default. Using "-fno-recomp" causes all modules to be recompiled, whether they changed or not. I think one of -frecomp or -fno-recomp-checking would be much clearer. But it's probably too late to change that... Best regards Tomasz
"Tomasz Zielonka"
BTW. The -fno-recomp option has a very unintuitive name, at least for me. When I see "-fno-recomp", my brain thinks "no recompilation", meaning "no unneccesary recompilation", which is what --make does by default. Using "-fno-recomp" causes all modules to be recompiled, whether they changed or not. I think one of -frecomp or -fno-recomp-checking would be much clearer. But it's probably too late to change that...
I believe this is worth fixing. Everytime I see "-fno-recomp" I always read it as no recompilation. A synonym could be added in 6.6. I would suggest -fforce-recomp for force recompilation. In 6.8 -fno-recomp could be flagged as obsolete. In 7.0 it could be removed. Rene.
participants (4)
-
Bulat Ziganshin -
Einar Karttunen -
Rene de Visser -
Tomasz Zielonka