cmd/link: clear up the Shlib record when building a pkg

[hengwu0]

The Shlib record of a pkg should be cleaned once the pkg is being built and packed to pkg.a（or using cached file pkg.a）.
Otherwise, the "packageshlib" key word in importcfg.link file will render the "packagefile" ineffective, in which the "packagefile" indicate the path of pkg.a( or cached pkg.a) and the "packageshlib" indicate the path of it's shlib( pkg's antiquated libXXX.so path ).

Fixes #26582

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[hengwu0]

I signed it!

[googlebot]

CLAs look good, thanks!

[gopherbot]

Message from Gerrit User 5976:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
Within the next week or so, a maintainer will review your change and provide
feedback. See https://golang.org/doc/contribute.html#review for more info and
tips to get your patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11, it means that this CL will be reviewed as part of the next development
cycle. See https://golang.org/s/release for more details.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 5065:

Patch Set 1:

Please file a bug about this so we can assign this to a release.

Also, include details of how to reproduce the failure.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[hengwu0]

The scene of recurring faults is rare. Somehow, #16602 can cause a link failure.
Steps:
1、 go install -buildmode=shared std
2、 go test -short -linkshared expvar

failure details:
# expvar (testmain) main.statictmp_0: relocation target expvar.TestNil·f not defined main.statictmp_0: relocation target expvar.TestInt·f not defined main.statictmp_0: relocation target expvar.TestFloat·f not defined main.statictmp_0: relocation target expvar.TestString·f not defined main.statictmp_0: relocation target expvar.TestMapInit·f not defined main.statictmp_0: relocation target expvar.TestMapCounter·f not defined main.statictmp_0: relocation target expvar.TestFunc·f not defined main.statictmp_0: relocation target expvar.TestHandler·f not defined main.statictmp_1: relocation target expvar.BenchmarkIntAdd·f not defined main.statictmp_1: relocation target expvar.BenchmarkIntSet·f not defined main.statictmp_1: relocation target expvar.BenchmarkFloatAdd·f not defined main.statictmp_1: relocation target expvar.BenchmarkFloatSet·f not defined main.statictmp_1: relocation target expvar.BenchmarkStringSet·f not defined main.statictmp_1: relocation target expvar.BenchmarkMapSet·f not defined main.statictmp_1: relocation target expvar.BenchmarkMapSetDifferent·f not defined main.statictmp_1: relocation target expvar.BenchmarkMapSetString·f not defined main.statictmp_1: relocation target expvar.BenchmarkMapAddSame·f not defined main.statictmp_1: relocation target expvar.BenchmarkMapAddDifferent·f not defined main.statictmp_1: relocation target expvar.BenchmarkMapAddSameSteadyState·f not defined main.statictmp_1: relocation target expvar.BenchmarkMapAddDifferentSteadyState·f not defined main.statictmp_1: relocation target expvar.BenchmarkRealworldExpvarUsage·f not defined /home/jim/golang/go/pkg/tool/linux_amd64/link: too many errors FAIL expvar [build failed]

Bug reason: The Shlib record of the pkg "expvar" should be cleaned once the expvar pkg being rebuilt. Otherwise, the "packageshlib" key word in importcfg.link file will render the "packagefile" ineffective, in which the "packagefile" indicate the path of pkg.a( or cached pkg.a) and the "packageshlib" indicate the path of it's shlib( antiquated path: pkg/linux_amd64_dynlink/libstd.so ).

[gopherbot]

Message from Gerrit User 28471:

Patch Set 1: Code-Review+1

Patch Set 1:

Please file a bug about this so we can assign this to a release.

Also, include details of how to reproduce the failure.

The scene of recurring faults is rare. Somehow, #16602 can cause a link failure.
Steps:
1、 go install -buildmode=shared std
2、 go test -short -linkshared expvar

failure details:

expvar (testmain)

main.statictmp_0: relocation target expvar.TestNil·f not defined
main.statictmp_0: relocation target expvar.TestInt·f not defined
main.statictmp_0: relocation target expvar.TestFloat·f not defined
main.statictmp_0: relocation target expvar.TestString·f not defined
main.statictmp_0: relocation target expvar.TestMapInit·f not defined
main.statictmp_0: relocation target expvar.TestMapCounter·f not defined
main.statictmp_0: relocation target expvar.TestFunc·f not defined
main.statictmp_0: relocation target expvar.TestHandler·f not defined
main.statictmp_1: relocation target expvar.BenchmarkIntAdd·f not defined
main.statictmp_1: relocation target expvar.BenchmarkIntSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkFloatAdd·f not defined
main.statictmp_1: relocation target expvar.BenchmarkFloatSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkStringSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapSetDifferent·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapSetString·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddSame·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddDifferent·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddSameSteadyState·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddDifferentSteadyState·f not defined
main.statictmp_1: relocation target expvar.BenchmarkRealworldExpvarUsage·f not defined
/home/jim/golang/go/pkg/tool/linux_amd64/link: too many errors
FAIL expvar [build failed]

Bug reason: The Shlib record of the pkg "expvar" should be cleaned once the expvar pkg being rebuilt. Otherwise, the "packageshlib" key word in importcfg.link file will render the "packagefile" ineffective, in which the "packagefile" indicate the path of pkg.a( or cached pkg.a) and the "packageshlib" indicate the path of it's shlib( antiquated path: pkg/linux_amd64_dynlink/libstd.so ).

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 5065:

Patch Set 1:

Patch Set 1: Code-Review+1

Patch Set 1:

Please file a bug about this so we can assign this to a release.

Also, include details of how to reproduce the failure.

The scene of recurring faults is rare. Somehow, #16602 can cause a link failure.
Steps:
1、 go install -buildmode=shared std
2、 go test -short -linkshared expvar

failure details:

expvar (testmain)

main.statictmp_0: relocation target expvar.TestNil·f not defined
main.statictmp_0: relocation target expvar.TestInt·f not defined
main.statictmp_0: relocation target expvar.TestFloat·f not defined
main.statictmp_0: relocation target expvar.TestString·f not defined
main.statictmp_0: relocation target expvar.TestMapInit·f not defined
main.statictmp_0: relocation target expvar.TestMapCounter·f not defined
main.statictmp_0: relocation target expvar.TestFunc·f not defined
main.statictmp_0: relocation target expvar.TestHandler·f not defined
main.statictmp_1: relocation target expvar.BenchmarkIntAdd·f not defined
main.statictmp_1: relocation target expvar.BenchmarkIntSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkFloatAdd·f not defined
main.statictmp_1: relocation target expvar.BenchmarkFloatSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkStringSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapSetDifferent·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapSetString·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddSame·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddDifferent·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddSameSteadyState·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddDifferentSteadyState·f not defined
main.statictmp_1: relocation target expvar.BenchmarkRealworldExpvarUsage·f not defined
/home/jim/golang/go/pkg/tool/linux_amd64/link: too many errors
FAIL expvar [build failed]

Bug reason: The Shlib record of the pkg "expvar" should be cleaned once the expvar pkg being rebuilt. Otherwise, the "packageshlib" key word in importcfg.link file will render the "packagefile" ineffective, in which the "packagefile" indicate the path of pkg.a( or cached pkg.a) and the "packageshlib" indicate the path of it's shlib( antiquated path: pkg/linux_amd64_dynlink/libstd.so ).

Please put these details on a new bug in GitHub.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 28471:

Patch Set 1:

Patch Set 1:

Patch Set 1: Code-Review+1

Patch Set 1:

Please file a bug about this so we can assign this to a release.

Also, include details of how to reproduce the failure.

The scene of recurring faults is rare. Somehow, #16602 can cause a link failure.
Steps:
1、 go install -buildmode=shared std
2、 go test -short -linkshared expvar

failure details:

expvar (testmain)

main.statictmp_0: relocation target expvar.TestNil·f not defined
main.statictmp_0: relocation target expvar.TestInt·f not defined
main.statictmp_0: relocation target expvar.TestFloat·f not defined
main.statictmp_0: relocation target expvar.TestString·f not defined
main.statictmp_0: relocation target expvar.TestMapInit·f not defined
main.statictmp_0: relocation target expvar.TestMapCounter·f not defined
main.statictmp_0: relocation target expvar.TestFunc·f not defined
main.statictmp_0: relocation target expvar.TestHandler·f not defined
main.statictmp_1: relocation target expvar.BenchmarkIntAdd·f not defined
main.statictmp_1: relocation target expvar.BenchmarkIntSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkFloatAdd·f not defined
main.statictmp_1: relocation target expvar.BenchmarkFloatSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkStringSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapSet·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapSetDifferent·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapSetString·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddSame·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddDifferent·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddSameSteadyState·f not defined
main.statictmp_1: relocation target expvar.BenchmarkMapAddDifferentSteadyState·f not defined
main.statictmp_1: relocation target expvar.BenchmarkRealworldExpvarUsage·f not defined
/home/jim/golang/go/pkg/tool/linux_amd64/link: too many errors
FAIL expvar [build failed]

Bug reason: The Shlib record of the pkg "expvar" should be cleaned once the expvar pkg being rebuilt. Otherwise, the "packageshlib" key word in importcfg.link file will render the "packagefile" ineffective, in which the "packagefile" indicate the path of pkg.a( or cached pkg.a) and the "packageshlib" indicate the path of it's shlib( antiquated path: pkg/linux_amd64_dynlink/libstd.so ).

Please put these details on a new bug in GitHub.

#26582

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 5206:

Patch Set 1:

(3 comments)

Thanks for sending this.

1. I don't understand why this is correct. What is the case where a package is built instead of a shared library?

2. This needs a test, probably in misc/cgo/testshared.

3. This seems likely to break gccgo, which checks .Shlib in the link method.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 28502:

Patch Set 1:

Patch Set 1:

(3 comments)

Thanks for sending this.

1. I don't understand why this is correct. What is the case where a package is built instead of a shared library?

2. This needs a test, probably in misc/cgo/testshared.

3. This seems likely to break gccgo, which checks .Shlib in the link method.

1、 There will be an "importcfg.link" file created when user is building program by go1.10.3. It seems the new feture of go1.10.3, not even go1.9 have it!
About the "importcfg.link" file, I found it's rule: the "packageshlib" key word in importcfg.link file will render the "packagefile" ineffective! It seems rignt.
But i also found that: When a pkg is being built to pkg.a, it's shlib path still unchanged! So, i think it must be forgot to reset! #26582 showed it.

2、 As this little changes that I think it is to tiny  to add a test.

3、 Will the gccgo create importcfg.link file??? I really think it have no business with gccgo. Gccgo is good:)

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 12446:

Uploaded patch set 2: Commit message was updated.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 12446:

Uploaded patch set 3: New patch set was added with same tree, parent, and commit message as Patch Set 2.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 12446:

Uploaded patch set 4: Commit message was updated.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 12446:

Uploaded patch set 5: New patch set was added with same tree, parent, and commit message as Patch Set 4.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 12446:

Uploaded patch set 6: Commit message was updated.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 12446:

Uploaded patch set 7: New patch set was added with same tree, parent, and commit message as Patch Set 6.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 5206:

Patch Set 7:

1. I don't understand why this is correct. What is the case where a package is built instead of a shared library?

2. This needs a test, probably in misc/cgo/testshared.

3. This seems likely to break gccgo, which checks .Shlib in the link method.

1、 There will be an "importcfg.link" file created when user is building program by go1.10.3. It seems the new feture of go1.10.3, not even go1.9 have it!
About the "importcfg.link" file, I found it's rule: the "packageshlib" key word in importcfg.link file will render the "packagefile" ineffective! It seems rignt.
But i also found that: When a pkg is being built to pkg.a, it's shlib path still unchanged! So, i think it must be forgot to reset! #26582 showed it.

Thanks, but I don't really understand this explanation. I understand the importcfg.link file. And I understand that it contains a packageshlib entry. But why is the packageshlib entry not correct? Why should we ignore it in this case but not others? What is different here?

2、 As this little changes that I think it is to tiny  to add a test.

I'm sorry, I disagree. The change may be small but the effect is large. If we don't have a test, the behavior could break again in the future.

3、 Will the gccgo create importcfg.link file??? I really think it have no business with gccgo. Gccgo is good:)

gccgo doesn't use the importcfg.link file, but my concern is that there is code in cmd/go/internal/work/gccgo.go that looks at the Shlib field. If the Shlib field is cleared, will that code continue to work correctly?

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 28502:

Patch Set 7:

Patch Set 7:

1. I don't understand why this is correct. What is the case where a package is built instead of a shared library?

2. This needs a test, probably in misc/cgo/testshared.

3. This seems likely to break gccgo, which checks .Shlib in the link method.

1、 There will be an "importcfg.link" file created when user is building program by go1.10.3. It seems the new feture of go1.10.3, not even go1.9 have it!
About the "importcfg.link" file, I found it's rule: the "packageshlib" key word in importcfg.link file will render the "packagefile" ineffective! It seems rignt.
But i also found that: When a pkg is being built to pkg.a, it's shlib path still unchanged! So, i think it must be forgot to reset! #26582 showed it.

Thanks, but I don't really understand this explanation. I understand the importcfg.link file. And I understand that it contains a packageshlib entry. But why is the packageshlib entry not correct? Why should we ignore it in this case but not others? What is different here?

Because the golang will compile the pkg first in the the "build" functon, and the result is _pkg_.a if the pkg need to be built. That means it only updated the "packagefile" entry only, and keep the dirty value of "packageshlib". I think the packageshlib should be cleaned at that moment in case the new _pkg_.a file be ignored to link in, if the packageshlib entry won't be updated since then.

It is not an exception, but a general operation process flow. And i think there have no negative impact to packageshlib entry if it will be updated in the later processing. But it do have influences if the packageshlib entry won't be updated after "build function", like #26582 showed.

2、 As this little changes that I think it is to tiny  to add a test.

I'm sorry, I disagree. The change may be small but the effect is large. If we don't have a test, the behavior could break again in the future.

i can append it later if you aggree to this patch:)

3、 Will the gccgo create importcfg.link file??? I really think it have no business with gccgo. Gccgo is good:)

gccgo doesn't use the importcfg.link file, but my concern is that there is code in cmd/go/internal/work/gccgo.go that looks at the Shlib field. If the Shlib field is cleared, will that code continue to work correctly?
I think it have no effect with the origin processing flow.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 6320:

Patch Set 7:

I tried this patch on ppc64le, and it results in an error when running misc/cgo/testshared:

../misc/cgo/testshared

--- FAIL: TestTrivialExecutable (4.26s)
shared_test.go:67: executing go install -installsuffix=5577006791947779410 -linkshared trivial failed exit status 2:
# trivial
/home/boger/golang/test.shared/go/pkg/tool/linux_ppc64le/link: cannot implicitly include runtime/cgo in a shared library
FAIL
exit status 1
FAIL _/home/boger/golang/test.shared/go/misc/cgo/testshared 42.798s
2018/07/30 09:58:55 Failed: exit status 1

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Gerrit User 28502:

Patch Set 7:

Patch Set 7:

I tried this patch on ppc64le, and it results in an error when running misc/cgo/testshared:

../misc/cgo/testshared

--- FAIL: TestTrivialExecutable (4.26s)
shared_test.go:67: executing go install -installsuffix=5577006791947779410 -linkshared trivial failed exit status 2:
# trivial
/home/boger/golang/test.shared/go/pkg/tool/linux_ppc64le/link: cannot implicitly include runtime/cgo in a shared library
FAIL
exit status 1
FAIL _/home/boger/golang/test.shared/go/misc/cgo/testshared 42.798s
2018/07/30 09:58:55 Failed: exit status 1

Perhaps there is something chaos and the patch may make "go install" failed in this test case.
Before I patched this patch,
I use this command: go test -c -o shared_test shared_test.go to build this test.
Then, run command ./shared_test -test.run=TrivialExecutable$ -test.v in the "misc/cgo/testshared" filepath.

The output(intercepted fragment):
=== RUN TestTrivialExecutable

• go install -installsuffix=5577006791947779410 -x -linkshared trivial
  WORK=/tmp/go-build519132624
  mkdir -p $WORK/b007/
  mkdir -p /home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/sync/
  cp /home/jim/.cache/go-build/16/1666abcaa4155c65e71bccc0c9e88972fe0c2dd6aa36392db5e690127b6df1e9-d /home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/sync/atomic.a
  rm -r $WORK/b007/
  mkdir -p $WORK/b006/
  mkdir -p /home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/runtime/
  cp /home/jim/.cache/go-build/e7/e7d27a00414185d5066e74427fa2fc629c439912a29e1846c6ce248d9a85bc8d-d /home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/runtime/cgo.a
  rm -r $WORK/b006/
  mkdir -p $WORK/b002/
  mkdir -p /home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/
  cp /home/jim/.cache/go-build/cc/cc9d2733a1a0b4ca555099e4ce243e23348833bbe9ecab4d473154a39d7a60fb-d /home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/runtime.a
  rm -r $WORK/b002/
  mkdir -p $WORK/b008/
  cat >$WORK/b008/importcfg.link << 'EOF' # internal
  packagefile runtime=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/runtime.a
  packageshlib runtime=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/libruntime,sync-atomic.so
  packagefile runtime/cgo=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/runtime/cgo.a
  packageshlib runtime/cgo=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/libruntime,sync-atomic.so
  packagefile runtime=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/runtime.a
  packageshlib runtime=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/libruntime,sync-atomic.so
  packagefile sync/atomic=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/sync/atomic.a
  packageshlib sync/atomic=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/libruntime,sync-atomic.so
  packagefile runtime/cgo=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/runtime/cgo.a
  packageshlib runtime/cgo=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/libruntime,sync-atomic.so
  packagefile runtime/internal/atomic=/home/jim/.cache/go-build/39/39ca4149d5390cc78916ff6111b404899d28fa386453860b71ced841ba8c31df-d
  packagefile runtime/internal/sys=/home/jim/.cache/go-build/b5/b582183adf3acfc66f5e240214da0840ea947fae68dd74f8f2f37c36f4b3f316-d
  EOF
  cd .
  /home/jim/golang/go/pkg/tool/linux_amd64/link -o $WORK/b008/libruntime,sync-atomic.so -importcfg $WORK/b008/importcfg.link -installsuffix 5577006791947779410_dynlink -buildmode=shared -linkshared -w -extld=gcc runtime=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/runtime.a sync/atomic=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/sync/atomic.a runtime/cgo=/home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/runtime/cgo.a
  echo 'libruntime,sync-atomic.so' > /home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/runtime.shlibname # internal
  echo 'libruntime,sync-atomic.so' > /home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/sync/atomic.shlibname # internal
  echo 'libruntime,sync-atomic.so' > /home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/runtime/cgo.shlibname # internal
  mv $WORK/b008/libruntime,sync-atomic.so /home/jim/golang/go/pkg/linux_amd64_5577006791947779410_dynlink/libruntime,sync-atomic.so

That log is the building log of libruntime,sync-atomic.so when doing the test. And, the libruntime,sync-atomic.so is being included in importcfg.link file before generated???
After pached my patches, it can let the "libruntime,sync-atomic.so" not being used when building itself. But it seems the shlib won't be updated which can let the test failed when building TestTrivialExecutable after that.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/125441.
After addressing review feedback, remember to publish your drafts!

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[gopherbot]

This PR (HEAD: 1f5f489) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/125441 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

[hengwu0]

I closed this meaningless pull request.
Fix mips64 instruction UNPREDICTABLE bug is another thing.