12

I maintain an open-source framework that uses CircleCI for continuous integration. I've recently hit a wall where the project suddenly refused to build in rather strange circumstances.

Build 27 was the last one that succeeded. After that, I made some minor changes to dependencies and noticed that the build fails. I've tried to fix it without success, so I reverted back to last working configuration and it still failed.

The reason for failure are two dependencies, both being bindings to native C libraries: OpenGL (OpenGLRaw) and GLFW (bindings-glfw). They error out in link stage with numerous lines of:

/tmp/ghc18975_0/ghc18975_6.o:(.data+0x0): multiple definition of `__stginit_bindizu0Qm7f8FzzUN32WFlos7AKUm_BindingsziGLFW'
/tmp/ghc18975_0/ghc18975_6.o:(.data+0x0): first defined here

I am totally stumped as for why that might happen. The exact same versions of those libraries were built back when the original build passed, and being on CI it uses a fresh container each time (I've tried cleaning the cache obviously). The build involves both apt-get update and cabal update though, so there's a possibility that some external resource was changed.

If anyone has ever encountered such or similar problem, it might vastly help in diagnosing and removing the issue. Google search for this specific multiple definition problem of that scale yields nothing.

I tried to update cabal version (since some hints over the internet pointed at it), but with:

cabal-install version 1.22.6.0
using version 1.22.4.0 of the Cabal library

The problem persists.

One important thing I forgot to mention is that this doesn't look strictly like some simple package mixup. I connected over SSH to that box, created an empty folder and a sandbox there, and even simple cabal install OpenGLRaw failed with the same problem (so it's unlikely that that itself would pull in two versions of the same module that could cause those conflicts).

I've also extracted a verbose cabal installation log.

Did SSH again, cloned raw sources of OpenGLRaw, still the same. Tried 7.6.3, still the same.

Bartek Banachewicz
  • 38,596
  • 7
  • 91
  • 135
  • 1
    I have a similar problem (also with CircleCI), but with `direct-sqlite-2.3.16`. – jpvillaisaza Jan 07 '16 at 15:50
  • 2
    Any luck? It seems like the same happens for `hslua`. See https://github.com/commercialhaskell/stack/issues/1624 and https://github.com/osa1/hslua/issues/40. – jpvillaisaza Jan 14 '16 at 22:06
  • 1
    @jpvillaisaza I've escalated to wherever I could; perhaps except Haskell reddit. Time to put the bounty up here and hope for the best. – Bartek Banachewicz Jan 14 '16 at 22:21
  • 1
    Try to add `-v3` ghc option and post the build log again too see what exactly `ghc` does here. I bet it is a mess with `--dynamic-too`. – Yuras Jan 15 '16 at 00:22
  • I get this with `cabal install direct-sqlite --verbose=3` using GHC 7.6.3: https://gist.github.com/jpvillaisaza/2864f74f15ff11cdd167. And this with `stack install direct-sqlite --cabal-verbose` (which I think is `v2`, not `v3`): https://gist.github.com/jpvillaisaza/31e8d0fe4fd072b2c5af. – jpvillaisaza Jan 15 '16 at 02:12
  • 1
    CircleCI announced a container image update about three weeks ago. I'm not sure if it fits the dates for this problem. This comment has a list of new versions for some programs: https://discuss.circleci.com/t/container-image-update-201512-01/1206/5. I'm also not sure if this is helpful. – jpvillaisaza Jan 15 '16 at 02:36
  • 1
    @jpvillaisaza could you please share `*.ldscript`, `*.o`, `*.s` and `*.c` files from [here](https://gist.github.com/jpvillaisaza/2864f74f15ff11cdd167#file-gistfile1-txt-L1063-L1070) Pass `-keep-tmp-files` to `ghc` to keep them. – Yuras Jan 15 '16 at 12:22
  • 2
    @jpvillaisaza Never mind I did that myself. And you was right, the issue occurs because of the container update. – Yuras Jan 15 '16 at 13:02

1 Answers1

14

It seems to be an issue with gcc-4.9.2. I forked your project, started a build with high verbosity level, connected to the circleci container and run the exact linking command. It fails the same way:

ubuntu@box1305:~$ /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as-needed -nostdlib -Wl,-r -nodefaultlibs '-Wl,--build-id=none' -o Types.o /tmp/ghc17998_0/ghc_15.ldscript
/tmp/ghc17998_0/ghc_14.o: In function `r2vy_closure':
(.data+0x0): multiple definition of `__stginit_OpenGzu8rT20eO9AxEKIONeYf57cS_GraphicsziRenderingziOpenGLziRawziTypes'
/tmp/ghc17998_0/ghc_14.o:(.data+0x0): first defined here
/tmp/ghc17998_0/ghc_14.o: In function `r2vy_closure':
(.data+0x8): multiple definition of `OpenGzu8rT20eO9AxEKIONeYf57cS_GraphicsziRenderingziOpenGLziRawziTypes_makeGLDEBUGPROC_closure'
/tmp/ghc17998_0/ghc_14.o:(.data+0x8): first defined here
/tmp/ghc17998_0/ghc_14.o: In function `c2y7_info':
(.text+0xc0): multiple definition of `OpenGzu8rT20eO9AxEKIONeYf57cS_GraphicsziRenderingziOpenGLziRawziTypes_makeGLDEBUGPROC_info'
/tmp/ghc17998_0/ghc_14.o:(.text+0xc0): first defined here

But with gcc-4.8 it works:

ubuntu@box1305:~$ /usr/bin/gcc-4.8 -fno-stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as-needed -nostdlib -Wl,-r -nodefaultlibs '-Wl,--build-id=none' -o Types.o /tmp/ghc17998_0/ghc_15.ldscript
ubuntu@box1305:~$

So you should switch to older gcc and probably report a bug to gcc devs.

ADDED: Here is an example how to switch gcc version. And here is a successful build.

slaphappy
  • 6,894
  • 3
  • 34
  • 59
Yuras
  • 13,856
  • 1
  • 45
  • 58