#9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by rzetterberg): My comment disappeared, so I'll try again! I encountered the same problem with a library I'm developing. My library uses a C++ static library that uses some Qt functionality. Qt has a tool called qmake that can generate makefiles for Qt-projects. When I looked at symbols in the library with the nm tool I saw that for each object file included __x86.get_pc_thunk.bx was exported. I looked at the generated makefile and saw that -fPIC was added to CFLAGS and CXXFLAGS. Which I thought was wierd since I'm building a static library. I removed -fPIC from CFLAGS and CXXFLAGS and rebuilt the library. When I looked at the symbols again __x86.get_pc_thunk.bx was not exported. I then ran {{{ cabal clean cabal configure cabal build }}} '''And my build was successful!''' I looked at the library that fails for you and I saw that in the cabal- file -fPIC is added to cc-options: https://github.com/coreyoconnor/vty/blob/master/vty.cabal#L117 Maybe that's the source of the problem? I'm no expert but it seems that this a library bug and not a ghc bug. Hopefully this saves the ghc devs and OP some time. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9657#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): <Fuuzetsu> @tell nomeata I just saw #9657 , and FTR there Vty has some GHC panic bugs open already so that might be worth looking for. Also Yi is known to have problem with Haddocking on 7.6.3 (#9170) so maybe this is the variant of that. By the way, I see you're using some patched sources for Vty 5.x support which makes this rather… hard to reproduce even if I wanted to [11:22] <lambdabot> nomeata lets you know: To reach me, better use mail than lambdabot messages; I tend to read them too late. <lambdabot> Consider it noted. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9657#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by rzetterberg): Replying to [comment:2 nomeata]:

Thanks for the investigation. I thought `-fPIC` is required in some cases, or for some architectures? But I must admint that I’m still mostly ignorant about linker issues.

That's true! After reading about linking a bit more: You need `-fPIC` on x86_64 when building shared libraries. And all static libaries that the shared library links against must also be built with `-fPIC`. I guess the "solution" I posted is more a non-portable hack. I'm not well versed in linking either. Hopefully it will atleast give some clues to the problem. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9657#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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