Opened 4 years ago

Closed 4 years ago

#9657 closed bug (wontfix)

I found a duplicate definition for symbol: __x86.get_pc_thunk.bx

Reported by: nomeata Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.6.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I am having problems building yi on 32 bit architectures (i386, hurd-i386, kfreebsd-i386) on Debian:

Loading package parallel-3.2.0.4 ... linking ... done.
Loading package reflection-1.2.0.1 ... linking ... done.
Loading package split-0.2.2 ... linking ... done.
Loading package utf8-string-0.3.7 ... linking ... done.
Loading package void-0.6.1 ... linking ... done.
Loading package zlib-0.5.4.1 ... linking ... done.
Loading package lens-4.1.2.1 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package terminfo-0.3.2.5 ... linking ... done.


GHCi runtime linker: fatal error: I found a duplicate definition for symbol
   __x86.get_pc_thunk.bx
whilst processing object file
   /usr/lib/haskell-packages/ghc/lib/i386-freebsd-ghc-7.6.3/vty-5.2.1/libHSvty-5.2.1.a
This could be caused by:
   * Loading two different object files which export the same symbol
   * Specifying the same object file twice on the GHCi command line
   * An incorrect `package.conf' entry, causing some object to be
     loaded twice.
GHCi cannot safely continue in this situation.  Exiting now.  Sorry.

(Full log at https://buildd.debian.org/status/fetch.php?pkg=yi&arch=kfreebsd-i386&ver=0.7.1-3&stamp=1410882226)

It does not happen on amd64. This happens on the Debian auto-builders and I did not reproduce it locally yet, but maybe someone can already tell me what’s wrong from looking at it.

Change History (7)

comment:1 Changed 4 years ago 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:

g++ -c -pipe -g -fPIC -D_REENTRANT -Wall -W ...

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.

Last edited 4 years ago by rzetterberg (previous) (diff)

comment:2 Changed 4 years ago by 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.

comment:3 Changed 4 years ago 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.

comment:4 Changed 4 years ago by nomeata

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

You can fetch the patch from http://anonscm.debian.org/darcs/pkg-haskell/yi/patches/vty-5.1-compat if you want to.

comment:5 in reply to:  2 Changed 4 years ago by rzetterberg

Replying to 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.

comment:6 Changed 4 years ago by siddhanathan

As of now, the issue is currently present on Yi HEAD (486367706a). 32bit Ubuntu 14.04 with no custom config.

comment:7 Changed 4 years ago by rwbarton

Resolution: wontfix
Status: newclosed

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?

Note: See TracTickets for help on using tickets.