8

When using the following in my stack.yaml to (attempt) to compile a static binary through Stack:

ghc-options:
    "*": -static -optc-static -optl-static -optl-pthread -fPIC

I get this error:

usr/bin/ld: /usr/lib/gcc/x86_64-amazon-linux/4.8.3/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-amazon-linux/4.8.3/crtbeginT.o: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)

I'm using stack with docker enabled and a customised Amazon Linux image for building a static binary for use with AWS Lambda.

I have no prior experience with static binary compilation, so I'm a bit stumped on this linker error. Any ideas please?

Here's the gcc args using -v:

/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as-needed -Wl,-rpath<snipped LOADS> -lHSghc<SNIPPED LOADS> -lpq -lz -lrt -lutil -ldl -lgmp
Alex
  • 8,093
  • 6
  • 49
  • 79
  • 2
    It would help if you could provide the failing `gcc` invocation. Probably adding `-v` to that `ghc-options` line would do it. – Reid Barton Jan 01 '17 at 22:31
  • 1
    something like this? https://ghc.haskell.org/trac/ghc/ticket/12759 – d8d0d65b3f7cf42 Jan 01 '17 at 23:30
  • Hmm, is this a bug then? Updated post with gcc call – Alex Jan 02 '17 at 07:19
  • 2
    [This blog post](https://www.fpcomplete.com/blog/2016/10/static-compilation-with-stack) which uses Alpine and Musl may be a more reliable approach. You can see it in practice in [this build script](https://github.com/fpco/stack-docker-image-build/blob/master/build-static.sh). – Michael Snoyman Jan 02 '17 at 07:53
  • Excellent post & example, but it unfortunately results in `Error parsing targets: The specified targets matched no packages. Perhaps you need to run 'stack init'?` – Alex Jan 02 '17 at 11:04
  • Why do you need a static linking? – ondra Jan 02 '17 at 11:14
  • Deploying to AWS Lambda fails with vrtsioning warnings and a returncode of - 11 if I bundle all libs. AWS recommends you deploy static bins to Lambda also. – Alex Jan 02 '17 at 12:06
  • Depends on libs you use, 7.10.3 (stack lts-6.25) binary seems to work on lambda withour problems. – ondra Jan 02 '17 at 12:53
  • I think you left out many important flags from the gcc invocation, such as the actual object files it is supposed to link, or the `-o` flag. – Reid Barton Jan 02 '17 at 13:21

2 Answers2

5

@Reid Barton is right, regarding the root cause of the problem. The real issue here is that stack is building a shared binary by default. By passing the options -static or ghc-options: -optl-static we are only addressing respectively the ghc layer and ld layer.

stack
 |_ cabal
      |_ ghc
          |_ gcc
              |_ ld (linker)

The correct way to solve the issue is to tell cabal that we want a static binary, as it pilots the build.

The answer on how to do that was provided by sausade on reddit: you just have to add the following to your .cabal file in the executable section:

directive:

`ld-options: -static`

This will hint to cabal that we want a static binary and as so it will not pass -shared to ghc.

So once you have added this directive in your cabal file, you just have to run:

stack install --ghc-options="-fPIC"

and voilà!

P.S: If you don't have static libraries on your system (like with Archlinux) ld will fallback to dynamic linking

Previous answer:

That's an old gcc issue that no one care to fix. https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/640734

For your original problem here are two useful links to show you how to do it:

Alex
  • 8,093
  • 6
  • 49
  • 79
Erèbe
  • 323
  • 1
  • 2
  • 8
2

I'm guessing a bit here, but I think this is just a case of breaking things by going behind the build system's back.

It's wrong to write

ghc-options:
    "*": -static

because the choice to build dynamic or static libraries has ramifications for how the rest of the build needs to go. Here it looks like Stack or Cabal told ghc to build a dynamic library and this flag overrode your attempt to set -static. As a result gcc probably ended up with the option combination -shared -static which led to the bug mentioned in Erèbe's answer. (If your flag -static had won over -dynamic, then ghc might have succeeded in building a static library but then Stack/Cabal would probably get confused about what to do next.)

The right way to do this is not to use -static in ghc-options, but instead tell Stack not to build a shared library in the first place. I don't know how you do that in Stack, but the Cabal flag is --disable-shared.

Reid Barton
  • 14,951
  • 3
  • 39
  • 49