#9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => wontfix Comment: The ghci linker doesn't understand whatever magic gcc/binutils uses to deduplicate multiple `__x86.get_pc_thunk.bx` symbols. That's not too surprising, there's a lot of kinds of magic that the ghci linker doesn't understand and this is one of the reasons that in 7.8 ghci uses dynamic libraries by default. I don't think the library author should need to specify `-fpic` in `cc- options` though. Cabal should invoke ghc with `-shared` when building the C files for a dynamic Haskell library, and ghc should then invoke gcc with `-fPIC`. In fact I just tried removing `-fpic` from `vty.cabal` and building it in a sandbox with `--ghc-options=-v` and I see {{{ /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O2 -O2 -x c \ cbits/mk_wcwidth.c -o /tmp/ghc11196_0/ghc11196_1.s -fPIC -U__PIC__ -D__PIC__ \ -Wimplicit -S '-D__GLASGOW_HASKELL__=708' [....] }}} so it seems that Cabal and ghc are both doing the right thing, and the vty author can remove `-fpic`. Maybe submit a bug report there? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9657#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler