[GHC] #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx

[GHC]

#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