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.

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.

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.

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.

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

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

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.

@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?

@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.

CL https://golang.org/cl/41628 mentions this issue.

CL https://golang.org/cl/41675 mentions this issue.

CL https://golang.org/cl/41678 mentions this issue.

CL https://golang.org/cl/41759 mentions this issue.

CL https://golang.org/cl/41798 mentions this issue.

I think the right fix here is for make.bash to auto-detect the desired default dynamic linker, and pass it in as we currently handle things like DEFAULTCC. Does someone want to work on that?

Not sure if this is the right place to ask this question. I understand the two basic problems with go on Alpine are to get the correct dynamic linker in the executable and to link in the right startup code to read the sysargs correctly. But I don't understand why Alpine wants to default to -buildmode=pie for all executables? It seems like in those cases where golang would build a static executable, that should be OK for Alpine, it is only when golang builds a dynamic executable that it should be building it pie-like.

Musl supports static PIE executables. We would like to default all executables (dynamic and static) to be PIE. This is due to the fact that ASLR works for main binary only when compiled in PIE mode.

@ianlancetaylor I can take a crack at it

how would you want this to change https://github.com/golang/go/blob/master/src/cmd/link/internal/amd64/obj.go#L70 a compile time variable or something?

@jessfraz I think it would be fine to make that a compile-time variable, along the lines of DefaultGOROOT and friends in cmd/internal/objabi/zbootstrap.go.

CL https://golang.org/cl/50070 mentions this issue.

@jessfraz Please don't hard code the dynamic linker name in the script as it's architecture specific. And you might want to check for musl c-library instead of alpine linux for wider compatibility.

also just curious as to why alpine does not use the default interpreter path?

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

@richfelker Maybe you can share insight on the interpreter name choice?

mark this issue.

@deanchina, I don't understand. What do you mean by "mark", and who are you addressing?

@fabled: I'm not sure what exactly you're looking for. The particular name choices are made so as to allow arbitrary arch/ABI combinations to exist in the same root filesystem. This matters especially for machines that support both 32- and 64-bit arch variants (also ILP32-on-64 ones) or multiple ABIs, but it's also intended to support execution of foreign binaries via something like qemu-user+binfmt_misc, or even exotic things like advanced multi-arch kernels on machines with multiple non-same-ISA cpus on the same board sharing memory and process space.

As for why it's different from glibc (aside from the above considerations and glibc's naming clashing between archs), it's so you can have both musl and glibc present in the same root fs. "ld-linux" is part of glibc and can't be used with musl, so reusing the same name would have precluded having both installed.

Change https://golang.org/cl/163977 mentions this issue: cmd/dist, cmd/link: allow passing default dynamic linker/loader

With the current solution, would it be possible to use the same instance of go to cross-compile binaries for different architectures (with different dynamic linkers/loaders)?