Opened 2 years ago

Last modified 18 months ago

#6107 new bug

GHCi runtime linker cannot link with duplicate common symbols

Reported by: exFalso Owned by:
Priority: normal Milestone: 7.8.3
Component: Compiler Version: 7.4.1
Keywords: Cc:
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By: #3658
Blocking: Related Tickets:

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 2 years ago.
DoesntWork.hs (72 bytes) - added by exFalso 2 years ago.
REPORT (1.7 KB) - added by exFalso 2 years ago.
works.c (66 bytes) - added by exFalso 2 years ago.
Works.hs (19 bytes) - added by exFalso 2 years ago.

Download all attachments as: .zip

Change History (9)

Changed 2 years ago by exFalso

Changed 2 years ago by exFalso

Changed 2 years ago by exFalso

Changed 2 years ago by exFalso

Changed 2 years ago by exFalso

comment:1 in reply to: ↑ description ; follow-up: Changed 2 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 2 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 18 months ago by igloo

  • Blocked By 3658 added

comment:4 Changed 18 months ago by igloo

  • Difficulty set to Unknown
  • Milestone set to 7.8.1
Note: See TracTickets for help on using tickets.