Confusing link error when specifying the same object repeatedly

Given foo.hs containing main = print 1 and foo.c containing void foo(){} , if you run:

$ ghc foo.o foo.hs
C:\Neil\temp\dupe-name>ghc foo.hs foo.o
[1 of 1] Compiling Main             ( foo.hs, foo.o )
Linking foo.exe ...
foo.o:fake:(.data+0x0): multiple definition of `__stginit_Main'
foo.o:fake:(.data+0x0): first defined here
foo.o:fake:(.data+0x10): multiple definition of `Main_main_closure'
foo.o:fake:(.data+0x10): first defined here
foo.o:fake:(.text+0x18): multiple definition of `Main_main_info'
foo.o:fake:(.text+0x18): first defined here
foo.o:fake:(.data+0x30): multiple definition of `ZCMain_main_closure'
foo.o:fake:(.data+0x30): first defined here
foo.o:fake:(.text+0x88): multiple definition of `ZCMain_main_info'
foo.o:fake:(.text+0x88): first defined here
foo.o:fake:(.data+0x70): multiple definition of `Main_zdtrModule_closure'
foo.o:fake:(.data+0x70): first defined here
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)

It seems GHC compiles both foo.hs and foo.c to foo.o, and then links foo.o twice. Sometimes foo.hs writes last, sometimes foo.c so the error can change. I found the error quite confusing, until I realised what it was doing.

One solution might be before linking .o files GHC does canonicalizePath on all the object files, and if any are duplicates, it raises a cleaner error. That check would also catch ghc foo.hs bar.o bar.o as well.

Trac metadata

Trac field	Value
Version	8.2.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture