recompile with -fPIC in debian

[dougnd]

Using a golang docker image (which I believe is based on Debian), I get the errors described in #6. Presumably they are appearing again because of #45.

16:12 $ docker run -it golang:1.11 /bin/bash
root@46ba7a1e3c11:/go# ls
bin  src
root@46ba7a1e3c11:/go# go get github.com/discordapp/lilliput
# github.com/discordapp/lilliput
/usr/bin/ld: src/github.com/discordapp/lilliput/deps/linux/lib/libswscale.a(swscale.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: src/github.com/discordapp/lilliput/deps/linux/lib/libswscale.a(utils.o): relocation R_X86_64_32S against `.bss' can not be used when making a shared object; recompile with -fPIC

Here's my thoughts:
Things work fine in the latest centos docker image. After some research, it looks like recent versions of gcc (6+) provide a "-pie" option by default that requires shared libraries be compiled with "fPIC". I found that if I added -no-pie to all the #cgo linux LDFLAGS: lines (and added -no-pie to CGO_LDFLAGS_ALLOW) it would build just fine in the golang:1.11 image.

I suppose we could also downgrade the version of gcc too.

My question: What do you guys do? Do you have build recommendations? It would be nice to put some stuff in the README so that future users don't stumble like I did. Or am I missing something obvious?

[brian-armstrong-discord]

Sorry to hear you got bit by this. The -no-pie option might be interesting. We had to turn off the fPIC mode because it caused a tremendous performance regression, but maybe the -no-pie mode wouldn't. It's worth looking into for sure.

[dougnd]

Yeah I don't know the best solution. I can setup a PR from https://github.com/dougnd/lilliput/tree/feature/no-pie if you like. It does work:

3:13 $ docker run -it golang:1.11 /bin/bash
root@2082aeec8cbc:/go# go get github.com/discordapp/lilliput
# github.com/discordapp/lilliput
/usr/bin/ld: src/github.com/discordapp/lilliput/deps/linux/lib/libswscale.a(swscale.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: src/github.com/discordapp/lilliput/deps/linux/lib/libswscale.a(utils.o): relocation R_X86_64_32S against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: src/github.com/discordapp/lilliput/deps/linux/lib/libswscale.a(vscale.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: src/github.com/discordapp/lilliput/deps/linux/lib/libswscale.a(hscale_fast_bilinear_simd.o): relocation R_X86_64_32S against `.text.unlikely' can not be used when making a shared object; recompile with -fPIC

[...and a lot more errors...]

root@2082aeec8cbc:/go# cd src/github.com/discordapp/lilliput/
root@2082aeec8cbc:/go/src/github.com/discordapp/lilliput# git remote add dougnd https://github.com/dougnd/lilliput
root@2082aeec8cbc:/go/src/github.com/discordapp/lilliput# git fetch dougnd
root@2082aeec8cbc:/go/src/github.com/discordapp/lilliput# git checkout feature/no-pie
root@2082aeec8cbc:/go/src/github.com/discordapp/lilliput# go build
go build github.com/discordapp/lilliput: invalid flag in #cgo LDFLAGS: -no-pie
root@2082aeec8cbc:/go/src/github.com/discordapp/lilliput# export CGO_LDFLAGS_ALLOW='-no-pie'
root@2082aeec8cbc:/go/src/github.com/discordapp/lilliput# go build
[...Success!...]

Notice that you'd need to set CGO_LDFLAGS_ALLOW to allow the -no-pie. So your library would no longer be go-gettable (without setting that env). Although it looks like they are soliciting more flags to be whitelisted, so I could make a request they whitelist -no-pie in future versions of Go.

I'd still be interested in how Discord builds this -- what OS, what version of GCC, etc. Clearly you guys don't run into this problem, so if there are preferred platforms, it might be nice to know.

Thanks!

[brian-armstrong-discord]

I appreciate the offer to help with the branch. I think in the short term, we're going to set up a branch that works in newer versions of Ubuntu so that you can fetch that sha instead. That will generally work cleaner, and in the long term, the repo will stop working on old versions of Ubuntu.

[paulm17]

@dougnd Thank you for supplying a fork.

I wasn't originally hit by this bug as I was running Centos. But now due to some issues I'm now running the latest debian. So I'm another one affected by this issue.

[EmpireJones]

In case this is helpful for others, I was able to work around this without branching, by calling export CGO_LDFLAGS='-no-pie' before calling go get github.com/discordapp/lilliput and go build.

[brian-armstrong-discord]

This is finally done. Please note that building with some flags can cause large performance impacts. Instead we now provide the binaries that will work on modern distributions.