cmd/link: regression for supporting PIE on Alpine X86_64 platform

[williamweixiao]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.8beta1 linux/amd64

What operating system and processor architecture are you using (go env)?

Alpine X86_64

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build585116893=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

What did you do?

# go build -buildmode=pie test/helloworld.go
# ./helloworld

What did you expect to see?

hello, world

What did you see instead?

sh: ./helloworld: not found

[williamweixiao]

I find that the root-cause is that go internal link provide a non-existed interpreter for Alpine

# readelf -l helloworld | grep interpreter
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

if i force using external linker then the issue won't appear

# go build -buildmode=pie -ldflags="-linkmode=external" test/helloworld.go
# ./helloworld
hello, world

since go is using external linker for PIE before 1.8, i think the issue as a regression.

[ianlancetaylor]

If Alpine uses a non-standard path to the dynamic linker, you will need to use go build -ldflags=-I/path/to/ld.so or, as you say, -ldflags=-linkmode=external. We don't have a way to set the default dynamic linker used in internal linking mode. Perhaps we can fix that for 1.9.

[williamweixiao]

yes, Alpine uses: /lib/ld-musl-x86_64.so.1 as it dynamic linker. But it seems hard to fix since Golang has no idea about target linux distros.

[ianlancetaylor]

If at all possible we should avoid adding alpine as a GOOS value. But we could add an environment variable to make.bash to set the default dynamic interpreter, and/or we could add some code to cmd/dist that tries to guess the default dynamic interpreter by compiling and linking a C program and examining the resulting executable.

[williamweixiao]

sounds doable! it would be good if golang can remove dependence on GCC (i mean after installed) and according development libraries since Alpine is pursuing a small size OS image

[bradfitz]

Go doesn't depend on GCC. You can choose to build static binaries, and you don't need GCC to do so.

[williamweixiao]

Yes, static binaries don't need GCC and I believe Go will finally remove all the dependence on GCC. Go is already trying to remove depend on GCC for X86 platform (such as internal linker for PIE) but for other platforms such as arm64, it still requires external (GCC) linker. Even for Alpine X86 which expects "PIE", Go internal linker has this bug and users have to use GCC linker.

[ncopa]

@ianlancetaylor If Alpine uses a non-standard path to the dynamic linker

Is there any standard that defines the path to the dynamic linker?

I would expect that /lib64/ld-linux-x86-64.so.2 also breaks android?

[ianlancetaylor]

@ncopa Standard dynamic linker paths are defined by the ELF ABI Supplement for the relevant processor.

I don't know what dynamic linker path Android uses, if any, but as far as I can see the Go cmd/link tool has no special support for choosing a different dynamic linker on Android, other than the previously mentioned -I option.