It's also possible that this is just a symptom of the cgo tool indiscriminately applying LDFLAGS at different parts of the build process and the test itself is "correct". I haven't investigated further yet.

So after further investigation, I've come to the conclusion that the real issue is not so much the test, as the fact that there seems to be no way to control when and how LDFLAGS are applied during the build process.

Some flags should only be applied when performing the linking step for a shared library or executable, etc. In other contexts, they're either invalid, or meaningless to apply (so should not be specified).

Go already manipulates the linker flags used depending on context, so perhaps something like this is sufficient:

diff --git a/src/cmd/go/build.go b/src/cmd/go/build.go
index 718edd2..fdf00f3 100644
--- a/src/cmd/go/build.go
+++ b/src/cmd/go/build.go
@@ -2972,6 +2972,12 @@ func (b *builder) cgo(p *Package, cgoExe, obj string, pcCFLAGS, pcLDFLAGS, cgofi
                // See issue 8788 for details.
                case strings.HasPrefix(f, "-fsanitize="):
                        continue
+               // runpath flags not applicable unless building a shared
+               // library; see issue 12115 for details. Since rpath expects an
+               // argument, both it and the following argument are skipped.
+               case buildBuildmode != "c-shared" && strings.HasPrefix(f, "-Wl,-rpath"):
+                       i+= 2
+                       continue
                default:
                        bareLDFLAGS = append(bareLDFLAGS, f)
                }

However, it seems like there's a larger issue -- namely, that Go should likely offer finer control over when LDFLAGS are applied.

I welcome any feedback or suggestions others might have.

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