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 |