Ticket #6107 (new bug)

Opened 12 months ago

Last modified 8 months ago

GHCi runtime linker cannot link with duplicate common symbols

Reported by: exFalso Owned by:
Priority: normal Milestone: 7.8.1
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

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

Change History

Changed 12 months ago by exFalso

Changed 12 months ago by exFalso

Changed 12 months ago by exFalso

Changed 12 months ago by exFalso

Changed 12 months ago by exFalso

in reply to: ↑ description ; follow-up: ↓ 2   Changed 12 months 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

in reply to: ↑ 1   Changed 12 months 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

  Changed 8 months ago by igloo

  • blockedby 3658 added

  Changed 8 months ago by igloo

  • difficulty set to Unknown
  • milestone set to 7.8.1
Note: See TracTickets for help on using tickets.