Opened 3 years ago

Last modified 2 months ago

#6107 new bug

GHCi runtime linker cannot link with duplicate common symbols

Reported by: exFalso Owned by:
Priority: normal Milestone: 7.12.1
Component: Compiler Version: 7.4.1
Keywords: Cc:
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: #8228 Blocking:
Related Tickets: Differential Revisions:

Description

GHCi's runtime linker reports duplicate common symbols as fatal error. According to the nm manual: "When linking, multiple common symbols may appear with the same name".
This means that for example one cannot link using the FFI with libraries having multiple common symbols if TH splices are used.

To illustrate let's create two object files both defining the same common symbol:

commonSym.c

volatile commonSym;
$ gcc -o commonSym.o commonSym.c -c
$ gcc -o commonSym2.o commonSym.c -c
$ nm commonSym.o commonSym2.o

commonSym.o:
0000000000000004 C commonSym

commonSym2.o:
0000000000000004 C commonSym

Now we create two dummy .hs files, one having a TH splice which (i'm guessing) triggers the runtime linker.

Works.hs

module Works where

DoesntWork.hs

{-# LANGUAGE TemplateHaskell #-}
module DoesntWork where
$(return [])
$ ghc Works.hs commonSym.o commonSym2.o
[1 of 1] Compiling Works            ( Works.hs, Works.o )

$ ghc DoesntWork.hs commonSym.o commonSym2.o
[1 of 1] Compiling DoesntWork       ( DoesntWork.hs, DoesntWork.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading object (static) commonSym.o ... done
Loading object (static) commonSym2.o ... 

GHCi runtime linker: fatal error: I found a duplicate definition for symbol
   commonSym
whilst processing object file
   commonSym2.o
(...)

Just to make sure that this -should- link:

works.c

extern commonSym;
int main (void)
{
    int _ = commonSym;
}
$ gcc -o works.o works.c -c
$ nm works.o
                 U commonSym
0000000000000000 T main
$ gcc -o works works.o commonSym.o commonSym2.o
$ ./works ; echo $?
0

Attachments (5)

commonSym.c (21 bytes) - added by exFalso 3 years ago.
DoesntWork.hs (72 bytes) - added by exFalso 3 years ago.
REPORT (1.7 KB) - added by exFalso 3 years ago.
works.c (66 bytes) - added by exFalso 3 years ago.
Works.hs (19 bytes) - added by exFalso 3 years ago.

Download all attachments as: .zip

Change History (12)

Changed 3 years ago by exFalso

Changed 3 years ago by exFalso

Changed 3 years ago by exFalso

Changed 3 years ago by exFalso

Changed 3 years ago by exFalso

comment:1 in reply to: ↑ description ; follow-up: Changed 3 years ago by exFalso

meanwhile, to anyone experiencing this problem, there is a quick hack to get around the runtime linker: define an object file with dummy symbols that you need:

#define DUM(SYM) SYM(void){}
DUM(commonSym);

then compile

$ gcc -o commonSymDummy.o commonSymDummy.c -c
$ nm commonSymDummy.o
0000000000000000 T commonSym
$ ghc DoesntWork.hs commonSymDummy.o
(...)
$ ghc Main.hs DoesntWork.o commonSym.o commonSym2.o
(...)

note, that the dummy symbols won't actually be used, they just need to be there for the runtime linker

comment:2 in reply to: ↑ 1 Changed 3 years ago by exFalso

sorry, correction to last comment: the last line should be (as Main.hs will import DoesntWork)

$ ghc Main.hs commonSym.o commonSym2.o

comment:3 Changed 2 years ago by igloo

  • Blocked By 3658 added

comment:4 Changed 2 years ago by igloo

  • difficulty set to Unknown
  • Milestone set to 7.8.1

comment:5 Changed 10 months ago by thoughtpolice

  • Milestone changed from 7.8.3 to 7.10.1

Moving to 7.10.1.

comment:6 Changed 3 months ago by thomie

  • Blocked By 8228 added; 3658 removed
  • Operating System changed from Linux to Windows

GHCi on Linux has been using the system linker since 7.8.1, see DynamicGhcPrograms and #3658. I'll leave this ticket open for Windows only.

comment:7 Changed 2 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

Note: See TracTickets for help on using tickets.