@cherrymui @rsc @mdempsky @ianlancetaylor @mwhudson

Hmm this doesn't reproduce for me on Ubuntu 18.04. I can't really see why that commit would break things here, I guess one would need to dump out the command line the linker is using to test compat and see why it fails...

This only fails for me on Debian 9.
I am seeing binutils 2.28 and gcc 6.3.0 on that system.
Ubuntu 18.04 has binutils 2.30 and gcc 7.3.0.

The -no-pie option was passed to the linker due to this issue #17847 but now it is removed.

Hmm this doesn't reproduce for me on Ubuntu 18.04. I can't really see why that commit would break things here, I guess one would need to dump out the command line the linker is using to test compat and see why it fails...

As I show above, before this commit, gcc was passing -no-pie to the external linker but after this commit it does not. At some point gcc started passing -pie by default to ld so golang had to pass -no-pie to override it.

Please use the go tool's -x option so that we can see exactly how cmd/link is being invoked, specifically so that we can see what the -extldflags option is.

CL 130316 was not supposed to change whether we pass -no-pie or not, it was just supposed to do a more accurate test of whether the external linker supports the option. Clearly that is breaking something for you, but we need to find out what is breaking and why.

Distros with binutils 2.29 or later don't fail. Debian 9 is the only one I found with 2.28. Perhaps a fix went in after 2.28 to fix a problem. I will try to track that down further.

This CL removes the -no-pie when invoking the external linker. Is that the correct/expected behavior?

I posted that last one before seeing your most recent comment.

Here is what I see when I hack into cmd/dist/test.go to add the -x option to the go build command (or is there any easier way to do that? Sure would help in debugging.)

/home/boger/golang/base/go/pkg/tool/linux_ppc64le/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -buildmode=exe -buildid=yOqLpa4EXqY0Lp2pUyTE/7HIRw7u34JSv5mK_5IeT/KNTcbpoY3nfiB17VRqFN/yOqLpa4EXqY0Lp2pUyTE -extld=gcc $WORK/b001/pkg.a
/home/boger/golang/base/go/pkg/tool/linux_ppc64le/buildid -w $WORK/b001/exe/a.out # internal
mv $WORK/b001/exe/a.out main.exe
rm -r $WORK/b001/
./main.exe: error while loading shared libraries: R_PPC64_ADDR16_HA re138199fe4 for symbol `' out of range

I don't see -extldflags. I think -no-pie gets set in this code in cmd/link/internal/ld/lib.go, not because it was passed as an argument to the linker.

// When building a program with the default -buildmode=exe the
    // gc compiler generates code requires DT_TEXTREL in a
    // position independent executable (PIE). On systems where the
    // toolchain creates PIEs by default, and where DT_TEXTREL
    // does not work, the resulting programs will not run. See
    // issue #17847. To avoid this problem pass -no-pie to the
    // toolchain if it is supported.
    if ctxt.BuildMode == BuildModeExe {
            src := filepath.Join(*flagTmpdir, "trivial.c")
            if err := ioutil.WriteFile(src, []byte("int main() { return 0; }"), 0666); err != nil {
                    Errorf(nil, "WriteFile trivial.c failed: %v", err)
            }

            // GCC uses -no-pie, clang uses -nopie.
            for _, nopie := range []string{"-no-pie", "-nopie"} {
                    cmd := exec.Command(argv[0], nopie, "trivial.c")
                    cmd.Dir = *flagTmpdir
                    cmd.Env = append([]string{"LC_ALL=C"}, os.Environ()...)
                    out, err := cmd.CombinedOutput()
                    // GCC says "unrecognized command line option ‘-no-pie’"
                    // clang says "unknown argument: '-no-pie'"
                    supported := err == nil && !bytes.Contains(out, []byte("unrecognized")) && !bytes.Contains(out, []byte("unknown"))
                    if supported {
                            argv = append(argv, nopie)
                            break
                    }
            }
    }

The only effect of CL 130316 that apparently caused this problem was to add the value of -extldflags to the external linker when testing whether -no-pie is supported. The code calls linkerFlagSupported to test whether -no-pie is supported. If it is, it is passed. CL 130316 changes linkerFlagSupported.

In the comment above you are quoting the old code. That's not what the linker code looks like now or in 1.11.

Can you change linkerFlagSupported to print exactly how it is invoking the external linker and what the linker is printing? Thanks.

When linkerFlagSupported was changed to pass extra linker options when linking trivial.c, this happens on Debian 9/binutils 2.28:

### linkerFlagSupported: gcc flags: [-g -O2 -L/home/boger/golang/bad/go/misc/cgo/testso -lcgosotest -g -O2 -lpthread -no-pie trivial.c] out: /home/boger/golang/bad/go/misc/cgo/testso/libcgosotest.so: undefined reference to `goCallback'
collect2: error: ld returned 1 exit status
 ###

So that causes linkerFlagSupported to return false for -no-pie since it contains the undefined string and -no-pie doesn't get added to the list of flags for ld.

I don't know why the linker error message from within linkerFlagSupported does not occur for other distros/binutils,. It is passing the same options to linkerFlagSupported on another system I tried.

@laboger Thanks. Working on a patch.

Change https://golang.org/cl/134057 mentions this issue: cmd/link: don't pass all linker args when testing flag