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

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

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 32 (18 by maintainers)

Commits related to this issue

Most upvoted comments

Thinking more the issue, if cross-building in Go is to be supported, you really need to know the target specific dynamic linker name. In alpine we patch it currently like: https://git.alpinelinux.org/cgit/aports/tree/community/go/set-external-linker.patch

However, it would probably make sense to add a new ld.Thearch.Musldyndl variable (or similar). And figure out whether to use musl or glibc by a build time or run-time automatically set option.

The default interpreter path is supported via compatibility package libc6-compat in Alpine (but probably not in other musl based distributions). However, the musl interpreter is preferred for natively built software. Alpine Linux uses the musl default interpreter name. To me the following reasons make sense:

  • musl is not fully ABI compatible with glibc (though, it is compatible where possible and several glibc programs run just fine on musl).
  • you can then install side-by-side glibc and musl, and programs linked against different c-library
  • musl keeps the arch subtype (e.g. hard vs. soft float, and big vs. little endian) as part of the interpreter name, which I think is not clear in all glibc variants