Peter Simons and I have just stumbled on a bug in the CVS version
of ghc --make that seems to have been introduced since the release
of 6.0, so I assume it is also buggy in the yet-to-be-released 6.2.
The nub of the bug is that ghc --make now names the object file for any
module Main as Main.o, disregarding the actual filename of the source.
(Previously, the .o was named to correspond to the .hs source file.)
When compiling more than one program which inhabit the same filesystem
directory, this leads the re-compilation dependency analysis astray.
ghc --make believes that the second Main module has already been
compiled, and so links a /different/ program's Main.o with the modules
imported by this program. The resultant linking errors are highly
confusing until you understand what is going on.
Here is an example.
file A.hs:
module Main where
import C
import D
main = do c; d
file B.hs:
module Main where
import C
main = do c
file C.hs:
module C where
c = putStrLn "hello"
file D.hs:
module D where
d = putStrLn "world"
Now try
ghc --make A; ghc --make B
In ghc-5.04.x and ghc-6.0, it works as expected. In ghc-6.3, it crashes like so:
Chasing modules from: A
Compiling D ( ./D.hs, ./D.o )
Compiling C ( ./C.hs, ./C.o )
Compiling Main ( ./A.hs, ./Main.o )
Linking ...
Chasing modules from: B
Skipping C ( ./C.hs, ./C.o )
Skipping Main ( ./B.hs, ./Main.o ) <-- error is here
Linking ...
./Main.o: In function `__stginit_Main_':
./Main.o(.text+0x25): undefined reference to `__stginit_D_'
./Main.o: In function `Main_main_srt':
./Main.o(.text+0x44): undefined reference to `D_d_closure'
./Main.o: In function `sGy_ret':
./Main.o(.text+0x5f): undefined reference to `D_d_closure'
collect2: ld returned 1 exit status
Regards,
Malcolm
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
