Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/x509: macOS -framework Security produces link warning #26073

Closed
rsc opened this Issue Jun 27, 2018 · 55 comments

Comments

Projects
None yet
@rsc
Copy link
Contributor

rsc commented Jun 27, 2018

See https://forums.developer.apple.com/thread/97850 for a bunch of people hitting a new link error in Xcode due to crypto/x509's use of the (apparently now deprecated?) -framework linker flag.

We could just take Merchant.Of.Satire's word for it, but it would be nice to have confirmation that we're not supposed to use -framework anymore, as opposed to some Xcode just being buggy/misconfigured/something else.

/cc @robpike who just hit this too.

@rsc rsc added this to the Go1.11 milestone Jun 27, 2018

@rsc rsc added the release-blocker label Jun 27, 2018

@robpike

This comment has been minimized.

Copy link
Contributor

robpike commented Jun 27, 2018

This is what the full build looks like:

% ./make.bash
Building Go cmd/dist using /usr/local/go.
Building Go toolchain1 using /usr/local/go.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for darwin/amd64.
# crypto/x509
ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.
---
Installed Go for darwin/amd64 in /Users/r/go
Installed commands in /Users/r/go/bin
% 

The offending invocation is in src/crypto/x509/root_cgo_darwin.go:

/*
#cgo CFLAGS: -mmacosx-version-min=10.10 -D__MAC_OS_X_VERSION_MAX_ALLOWED=101300
#cgo LDFLAGS: -framework CoreFoundation -framework Security

...
@meling

This comment has been minimized.

Copy link

meling commented Jul 14, 2018

FYI: I get this also with Go 1.10.3 and the macOS 10.13.6 (17G65).

% go version
go version go1.10.3 darwin/amd64
% go build
# github.com/autograde/aguis
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.
% uname -a
Darwin blast.local 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
@andybons

This comment has been minimized.

Copy link
Member

andybons commented Aug 3, 2018

The -framework linker flag isn’t deprecated from what I can tell.

This is due to an out-of-sync Xcode/command line tools installation. You can try updating Xcode (if you’re running an outdated version) and then launch it to install the latest command-line tools.

If you already have the latest Xcode (or the above doesn’t solve your issue), you can re-install the command-line tools forcibly per http://sd.jtimothyking.com/2018/07/26/stub-file-and-library-file-out-of-sync/:

$ sudo mv /Library/Developer/CommandLineTools /Library/Developer/CommandLineTools.old
$ xcode-select --install
$ sudo rm -rf /Library/Developer/CommandLineTools.old

If this doesn’t work please re-open this bug and I’ll do more investigating.

@andybons andybons closed this Aug 3, 2018

@robpike

This comment has been minimized.

Copy link
Contributor

robpike commented Aug 3, 2018

Verified that those instructions resolved it for me.

@YoshikiShibata

This comment has been minimized.

Copy link

YoshikiShibata commented Sep 17, 2018

This morning, I just upgraded the XCode and Command Line Tools (see the attached screen shot: sorry for Japanese), and then this problem appears again when I run all.bash for the tip version to rebuild everything.

2018-09-18 8 35 08

# crypto/x509
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.
@cneill

This comment has been minimized.

Copy link

cneill commented Sep 18, 2018

While attempting to build my project (which relies on sqlite3) from macOS High Sierra (10.13.6), for use in a Linux Docker container, I set the environment variable CGO_ENABLED=0 and built the project. It turns out that this was not what I needed to do. Now (even after updating XCode & reinstalling XCode Command Line Tools) I get the warnings mentioned above.

Output from go build -v:

...

# crypto/x509
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.

...

# github.com/cneill/project
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.
@hhhizzz

This comment has been minimized.

Copy link

hhhizzz commented Sep 18, 2018

update the Command Line Tools Just now, and similar issue

# command-line-arguments
ld: warning: text-based stub file /System/Library/Frameworks//Foundation.framework/Foundation.tbd and library file /System/Library/Frameworks//Foundation.framework/Foundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//IOKit.framework/IOKit.tbd and library file /System/Library/Frameworks//IOKit.framework/IOKit are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//DiskArbitration.framework/Versions/A/DiskArbitration.tbd and library file /System/Library/Frameworks//DiskArbitration.framework/Versions/A/DiskArbitration are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//CFNetwork.framework/Versions/A/CFNetwork.tbd and library file /System/Library/Frameworks//CFNetwork.framework/Versions/A/CFNetwork are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//CoreServices.framework/Versions/A/CoreServices.tbd and library file /System/Library/Frameworks//CoreServices.framework/Versions/A/CoreServices are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices.tbd and library file /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices.tbd and library file /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList.tbd and library file /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//ServiceManagement.framework/Versions/A/ServiceManagement.tbd and library file /System/Library/Frameworks//ServiceManagement.framework/Versions/A/ServiceManagement are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory.tbd and library file /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS.tbd and library file /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS are out of sync. Falling back to library file for linking.
/private/var/folders/x4/qr3r88l91y960q88lyh7vlg80000gn/T/___go_build_main_go #gosetup
@mqy

This comment has been minimized.

Copy link

mqy commented Sep 18, 2018

macOS 10.13.6 (17G65)
go version go1.10.4 darwin/amd64
After upgrade command line tools to 10.0, and upgrade xcode to 10.0:

go build a program (with CGO), got errors:

ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.

===

Tried fix with xcode-select --install, but the command line tools was installed as version 9.4.
Go build still those errors. Restart machine does not work.

@syhlion

This comment has been minimized.

Copy link

syhlion commented Sep 18, 2018

10.13.6(17G65)
go version go1.11 darwin/amd64

I have the same error

# crypto/x509
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.
@agnivade

This comment has been minimized.

Copy link
Member

agnivade commented Sep 18, 2018

Re-opening as per @andybons' comment

If this doesn’t work please re-open this bug and I’ll do more investigating.

@agnivade agnivade reopened this Sep 18, 2018

@agnivade agnivade modified the milestones: Go1.11, Go1.12 Sep 18, 2018

@agnivade

This comment has been minimized.

Copy link
Member

agnivade commented Sep 18, 2018

Reminder on our +1 policy https://github.com/golang/go/wiki/NoPlusOne.

@golang golang deleted a comment from kaidiren Sep 18, 2018

@golang golang deleted a comment from monoflash Sep 18, 2018

@andybons

This comment has been minimized.

Copy link
Member

andybons commented Sep 18, 2018

Can new reporters please confirm that reinstalling the command-line tools via

$ sudo mv /Library/Developer/CommandLineTools /Library/Developer/CommandLineTools.old
$ xcode-select --install
$ sudo rm -rf /Library/Developer/CommandLineTools.old

Does NOT solve your issue?

One notable thing I do not see in my App Store update list is the command-line tools as a separate item. I updated to Xcode 10.0, launched Xcode, then said yes when it asked to install additional components.

@calmh

This comment has been minimized.

Copy link
Contributor

calmh commented Sep 18, 2018

It might be OS dependent. My Mojave laptop acted exactly as you described above (Xcode 10, nothing specific about command line tools) and Go works fine there. My High Sierra desktop offers Xcode and a new Command Line Tools. (I've not accepted that upgrade there.)

@monoflash

This comment has been minimized.

Copy link

monoflash commented Sep 18, 2018

OS: macOS 10.13.6 (17G65) (High Sierra)
XCode version 10.0 (10A255)
go version go1.11 darwin/amd64

Solution with delete and reinstall CommandLineTools don't work!!!

I has disabled the warnings with environment variables:

export CGO_LDFLAGS="-g -O2 -w"
export WARNING_LDFLAGS=-w
export OTHER_LDFLAGS=-w

But this is not a solution, it's just postponing the problem "for later"!

@bahadir60

This comment has been minimized.

Copy link

bahadir60 commented Sep 18, 2018

After Updating I experienced same problem
GO: go1.10.4 darwin/amd64
CLT: 10.0
XCODE: 10.0

ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are outof sync. Falling back to library file for linking.

@piisoftware

This comment has been minimized.

Copy link

piisoftware commented Sep 18, 2018

OS: 10.13.6
golang version go1.9.2 darwin/amd64
XCode NOT currently installed, only the command-line tools

I'm seeing the same error; reinstalling command line tools had no effect.

@dmitshur

This comment has been minimized.

Copy link
Member

dmitshur commented Sep 18, 2018

As another data point, I am not seeing any ld warnings on the following configuration:

OS: macOS High Sierra, version 10.13.6 (17G65)
Go version: current tip at 2018-09-18 21:34 (d24ec86)
Xcode: not installed
Xcode CLI tools: version 9.4.1.0.1.1528165917 (via pkgutil --pkg-info=com.apple.pkg.CLTools_Executables)

I have another MacBook with Xcode 10 an latest CLI at home, will try on it later and edit in the result.

Edit: Second data point, I am seeing ld warnings on the following configuration:

OS: macOS High Sierra, version 10.13.6 (17G65)
Go version: current tip at 2018-09-18 21:34 (d24ec86)
Xcode: version 10.0 (10A255) (installed, but haven't done the "install additional required components" yet)
Xcode CLI tools: version 10.0.0.0.1.1535735448 (via pkgutil --pkg-info=com.apple.pkg.CLTools_Executables)

They are:

# crypto/x509
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.

I have then tried to run Xcode 10.0 and do the "install additional required components" step, the ld warnings persistent.

Then I tried sudo mv /Library/Developer/CommandLineTools /Library/Developer/CommandLineTools.old; xcode-select --install. It installed an older version of CLI tools 9.4.0.0.1.1526532315. The ld warnings persisted.

Then I got an update for CLI tools in App Store, installed it, and they were back to 10.0.0.0.1.1535735448. The ld warnings still persisted.

So, I can confirm this is a real issue, and it's reproducible with Xcode 10 and CLI tools installed.

Edit 2: macOS Mojave is due to be released on Monday. Updating to it may have an effect (i.e., in turn making this a High Siera-only issue).

@golang golang unlocked this conversation Sep 25, 2018

@zdebra

This comment has been minimized.

Copy link

zdebra commented Sep 26, 2018

I've just upgraded to macos Mojave and the issue remains.

OS: macOS Mojave, version 10.14
Go: go1.11 darwin/amd64

I don't have Xcode installed, only Xcode CLI tools. I've tried to reinstall Xcode CLI tools with no success.

@dmitshur

This comment has been minimized.

Copy link
Member

dmitshur commented Sep 26, 2018

@zdebra Thanks. What version of Xcode CLI tools? You should be able to find out by running pkgutil --pkg-info=com.apple.pkg.CLTools_Executables or so.

@zdebra

This comment has been minimized.

Copy link

zdebra commented Sep 26, 2018

@dmitshur

package-id: com.apple.pkg.CLTools_Executables
version: 10.0.0.0.1.1535735448
volume: /
location: /
install-time: 1537947903
groups: com.apple.FindSystemFiles.pkg-group
@nfarah86

This comment has been minimized.

Copy link

nfarah86 commented Sep 29, 2018

I've also tried installing an older version of xcode, tried moving, installing, and removing xcode per commands above, and reinstalled it. I get the warnings still. I'm on mac OS High Sierra, 10.13.6.

@geomacy

This comment has been minimized.

Copy link

geomacy commented Oct 1, 2018

@Quesomora's solution works for me (thanks! the linker errors break godog, so this is a great help)

OSX 10.13.6
go version go1.10.4 darwin/amd64 (but the problem occurs for go 1.11 as well).

xcode command line utils before applying Quesomora's suggestion, problem exists:

$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: 10.0.0.0.1.1535735448

xcode command line tools after applying the suggestion, problem gone:

$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: 9.4.1.0.1.1528165917

Unfortunately I guess this is going to mean turning off auto-update on packages, until Apple fix this.

@vassudanagunta

This comment has been minimized.

Copy link

vassudanagunta commented Oct 1, 2018

Confirmed @Quesomora's solution, exactly same environment and before/after as @geomacy with the excepton of go version go1.11 darwin/amd64.

@hilben

This comment has been minimized.

Copy link

hilben commented Oct 2, 2018

@Quesomora solution was not working for me until I downgraded go 1.11 to go 1.9.2 (i did not try 1.10)
Currently running with:

go version 
go1.9.2 darwin/amd64
pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: 9.4.0.0.1.1526532315
volume: /
location: /
install-time: 1538486245
groups: com.apple.FindSystemFiles.pkg-group
macOS 10.13.6
@requaos

This comment has been minimized.

Copy link

requaos commented Oct 2, 2018

I am working in a cgo project, using goconvey regularly during development, and goconvey interprets the ld errors as build failure indications.

macOS 10.13.6
go version
go version go1.11 darwin/amd64
pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: 10.0.0.0.1.1535735448
volume: /
location: /
install-time: 1538487003
groups: com.apple.FindSystemFiles.pkg-group 
@vassudanagunta

This comment has been minimized.

Copy link

vassudanagunta commented Oct 3, 2018

@requaos you have version: 10.0.0.0.1.1535735448 which if you search the comments above all point to it being a/the problematic version. Have you tried @Quesomora solution getting you to version: 9.4.1.0.1.1528165917? That seems to solve it for everyone that reported that version, including me.

@geomacy

This comment has been minimized.

Copy link

geomacy commented Oct 3, 2018

hi @Baha-sk, regarding

I opened a support ticket at Apple to fix this for future updates yesterday... not sure if/when they will fix it.. it is annoying to having to uninstall then reinstall the CLI tools every time there's a Mac dev tools update just to remove these warnings.

could you post a link to the ticket here so we could keep an eye on whether there appears to be any action on fixing this?

@xackery

This comment has been minimized.

Copy link

xackery commented Oct 4, 2018

followed @Quesomora 's fix but still getting the warning.

$  pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: 9.4.1.0.1.1528165917
volume: /
location: /
install-time: 1538424576
groups: com.apple.FindSystemFiles.pkg-group

$ go version
go version go1.11 darwin/amd64

macOS 10.13.6

9.4.1 seems to be applied, too.. Hmm.

@gabolaev

This comment has been minimized.

Copy link

gabolaev commented Oct 5, 2018

This issue is no longer detected on my machine after updating to macOS 10.14 Mojave

❯ xcodebuild -version
Xcode 10.0
Build version 10A255

❯ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.14
BuildVersion:	18A391

❯ go version
go version go1.9.7 darwin/amd64
@kevinburke

This comment has been minimized.

Copy link
Contributor

kevinburke commented Oct 8, 2018

@gabolaev I don't think that the issue reproduces with go 1.9 under any hardware configuration - it's Go 1.10 and above.

@gazed

This comment has been minimized.

Copy link

gazed commented Oct 8, 2018

Deleting the Xcode, the Xcode command line tools, and then reinstalling macOS 10.14 from macOS Recovery fixed the link warning problem for me. A bit drastic - but does this fix it for anyone else? Reinstalled the latest Xcode and Xcode command line tools after the OS reinstall.

Note: I had also reinstalled go version go1.11.1 darwin/amd64 after trying go1.9 and go.10. Also used go clean -cache.

Historical Note: the link warning issue started happening for my go projects after updating to macOS 10.14. Various combinations of reinstalling Xcode command line tools and Xcode did not fix the issue.
At one point the link warnings were happening even when using clang command line to compile a c-test program that used frameworks (no go involved).

@ParityError

This comment has been minimized.

Copy link

ParityError commented Oct 9, 2018

@requaos you have version: 10.0.0.0.1.1535735448 which if you search the comments above all point to it being a/the problematic version. Have you tried @Quesomora solution getting you to version: 9.4.1.0.1.1528165917? That seems to solve it for everyone that reported that version, including me.

Nope, I don't think that is the issue because I have the exact same problem and this is my version:

$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: 8.2.0.0.1.1480973914
volume: /
location: /
install-time: 1539050324
groups: com.apple.FindSystemFiles.pkg-group 

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.6
BuildVersion:	17G65

$ xcodebuild -version
Xcode 10.0
Build version 10A255

$ go version
go version go1.9.1 darwin/amd64

TBH this nothing to do with go either...

@gabolaev

This comment has been minimized.

Copy link

gabolaev commented Oct 9, 2018

@kevinburke, i had that issue on the same go version (1.9.7) on High Sierra. it's gone just after system update.

@requaos

This comment has been minimized.

Copy link

requaos commented Oct 9, 2018

@andybons

This comment has been minimized.

Copy link
Member

andybons commented Oct 10, 2018

Thanks everyone. We've filed a Radar (bug) with Apple and are awaiting their response.

This is not a Go-specific issue and is not dependent on the version of Go installed. We've provided the following reproduction steps to Apple:

Steps to Reproduce:
$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
version: 10.0.0.0.1.1535735448
$ clang --version
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
$ cat > issue.c 
int main() { return 0; }
^D
$ clang issue.c -framework CoreFoundation
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.

Locking for now while we wait for Apple's response. Thanks again, everyone.

@golang golang locked and limited conversation to collaborators Oct 10, 2018

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Oct 24, 2018

Change https://golang.org/cl/144112 mentions this issue: cmd/go, cmd/link: silence bogus Apple Xcode warning

@rsc

This comment has been minimized.

Copy link
Contributor Author

rsc commented Oct 24, 2018

I sent a CL to filter out the warning in our tools. There's no point in continuing to have people hit what looks like a real problem when we know it's a harmless bug on Apple's end. We should probably have done this months ago, and probably the CL should be backported to Go 1.11.

@gopherbot gopherbot closed this in 66bb8dd Oct 25, 2018

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Oct 29, 2018

Change https://golang.org/cl/145458 mentions this issue: [release-branch.go1.11] cmd/go, cmd/link: silence bogus Apple Xcode warning

gopherbot pushed a commit that referenced this issue Oct 29, 2018

[release-branch.go1.11] cmd/go, cmd/link: silence bogus Apple Xcode w…
…arning

Certain installations of Xcode are affected by a bug that causes
them to print an inconsequential link-time warning that looks like:

	ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.

This has nothing to do with Go, and we've sent this repro case
to Apple:

	$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
	version: 10.0.0.0.1.1535735448
	$ clang --version
	Apple LLVM version 10.0.0 (clang-1000.10.44.2)
	Target: x86_64-apple-darwin17.7.0
	Thread model: posix
	InstalledDir: /Library/Developer/CommandLineTools/usr/bin
	$ cat > issue.c
	int main() { return 0; }
	^D
	$ clang issue.c -framework CoreFoundation
	ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
	$

Even if Apple does release a fixed Xcode, many people are seeing
this useless warning, and we might as well make it go away.

Fixes #26073.

Change-Id: Ifc17ba7da1f6b59e233c11ebdab7241cb6656324
Reviewed-on: https://go-review.googlesource.com/c/144112
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
(cherry picked from commit 66bb8dd)
Reviewed-on: https://go-review.googlesource.com/c/145458
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

changkun added a commit to changkun/go that referenced this issue Nov 30, 2018

go1.11.2 updates tracking (#2)
* [release-branch.go1.11] doc/go1.11, cmd/go: elaborate on new GOFLAGS environment variable

In Go 1.11, cmd/go gained support for the GOFLAGS environment variable.
It was added and described in detail in CL 126656.
Mention it in the Go 1.11 release notes, link to the cmd/go documentation,
and add more details there.

Fixes golang#27387.

Change-Id: Ifc35bfe3e0886a145478d36dde8e80aedd8ec68e
Reviewed-on: https://go-review.googlesource.com/135035
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Rob Pike <r@golang.org>
(cherry picked from commit 58c6afe)
Reviewed-on: https://go-review.googlesource.com/135496
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

* [release-branch.go1.11] net/http: ensure null body in Fetch response is not read

The Fetch API returns a null body if there is no response body,
on browsers that support streaming the response body. This
change ensures we check for both undefined and null bodies
before attempting to read the body.

Fixes golang#27424

Change-Id: I0da86b61284fe394418b4b431495e715a037f335
Reviewed-on: https://go-review.googlesource.com/131236
Reviewed-by: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit ce53683)
Reviewed-on: https://go-review.googlesource.com/136915

* [release-branch.go1.11] runtime: ignore races between close and len/cap

They aren't really races, or at least they don't have any
observable effect. The spec is silent on whether these are actually
races or not.

Fix this problem by not using the address of len (or of cap)
as the location where channel operations are recorded to occur.
Use a random other field of hchan for that.

I'm not 100% sure we should in fact fix this. Opinions welcome.

Fixes golang#27778

Change-Id: Ib4efd4b62e0d1ef32fa51e373035ef207a655084
Reviewed-on: https://go-review.googlesource.com/135698
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
(cherry picked from commit 83dfc3b)
Reviewed-on: https://go-review.googlesource.com/138179
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] net: fail fast for DNS rcode success with no answers of requested type

DNS responses which do not contain answers of the requested type return
errNoSuchHost, the same error as rcode name error. Prior to
golang.org/cl/37879, both cases resulted in no additional name servers
being consulted for the question. That CL changed the behavior for both
cases. Issue golang#25336 was filed about the rcode name error case and
golang.org/cl/113815 fixed it. This CL fixes the no answers of requested
type case as well.

Updates golang#27525
Fixes golang#27537

Change-Id: I52fadedcd195f16adf62646b76bea2ab3b15d117
Reviewed-on: https://go-review.googlesource.com/133675
Run-TryBot: Ian Gudger <igudger@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 94f48dd)
Reviewed-on: https://go-review.googlesource.com/138175
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] cmd/go: add GOMIPS value to build id for mipsle

Strip a trailing "le" from the GOARCH value when calculating the GOxxx
environment variable that affects it.

Updates golang#27260
Fixes golang#27420

Change-Id: I081f30d5dc19281901551823f4f56be028b5f71a
Reviewed-on: https://go-review.googlesource.com/131379
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 61318d7)
Reviewed-on: https://go-review.googlesource.com/138176
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] doc: add go1.11 to contrib.html

Missing from https://golang.org/project

Change-Id: I6cb769ae861a81f0264bae624b5fe8d70aa92497
Reviewed-on: https://go-review.googlesource.com/138356
Reviewed-by: Chris Broadfoot <cbro@golang.org>

* [release-branch.go1.11] reflect: use correct write barrier operations for method funcs

Fix the code to use write barriers on heap memory, and no
write barriers on stack memory.

These errors were discovered as part of fixing golang#27695. They may
have something to do with that issue, but hard to be sure.
The core cause is different, so this fix is a separate CL.

Update golang#27867

Change-Id: Ib005f6b3308de340be83c3d07d049d5e316b1e3c
Reviewed-on: https://go-review.googlesource.com/137438
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit e35a412)
Reviewed-on: https://go-review.googlesource.com/138581
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] reflect: ensure correct scanning of return values

During a call to a reflect-generated function or method (via
makeFuncStub or methodValueCall), when should we scan the return
values?

When we're starting a reflect call, the space on the stack for the
return values is not initialized yet, as it contains whatever junk was
on the stack of the caller at the time. The return space must not be
scanned during a GC.

When we're finishing a reflect call, the return values are
initialized, and must be scanned during a GC to make sure that any
pointers in the return values are found and their referents retained.

When the GC stack walk comes across a reflect call in progress on the
stack, it needs to know whether to scan the results or not. It doesn't
know the progress of the reflect call, so it can't decide by
itself. The reflect package needs to tell it.

This CL adds another slot in the frame of makeFuncStub and
methodValueCall so we can put a boolean in there which tells the
runtime whether to scan the results or not.

This CL also adds the args length to reflectMethodValue so the
runtime can restrict its scanning to only the args section (not the
results) if the reflect package says the results aren't ready yet.

Do a delicate dance in the reflect package to set the "results are
valid" bit. We need to make sure we set the bit only after we've
copied the results back to the stack. But we must set the bit before
we drop reflect's copy of the results. Otherwise, we might have a
state where (temporarily) no one has a live copy of the results.
That's the state we were observing in issue golang#27695 before this CL.

The bitmap used by the runtime currently contains only the args.
(Actually, it contains all the bits, but the size is set so we use
only the args portion.) This is safe for early in a reflect call, but
unsafe late in a reflect call. The test issue27695.go demonstrates
this unsafety. We change the bitmap to always include both args
and results, and decide at runtime which portion to use.

issue27695.go only has a test for method calls. Function calls were ok
because there wasn't a safepoint between when reflect dropped its copy
of the return values and when the caller is resumed. This may change
when we introduce safepoints everywhere.

This truncate-to-only-the-args was part of CL 9888 (in 2015). That
part of the CL fixed the problem demonstrated in issue27695b.go but
introduced the problem demonstrated in issue27695.go.

TODO, in another CL: simplify FuncLayout and its test. stack return
value is now identical to frametype.ptrdata + frametype.gcdata.

Update golang#27867

Change-Id: I2d49b34e34a82c6328b34f02610587a291b25c5f
Reviewed-on: https://go-review.googlesource.com/137440
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/138582
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] reflect: fix s390x reflect method calls

R0 isn't the zero register any more. Oops.

Update golang#27867

Change-Id: I46a975ed37d5e570afe2e228d3edf74949e08ad7
Reviewed-on: https://go-review.googlesource.com/138580
Reviewed-by: Michael Munday <mike.munday@ibm.com>
Reviewed-on: https://go-review.googlesource.com/138583
Run-TryBot: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] net: concatenate multiple TXT strings in single TXT record

When go resolver was changed to use dnsmessage.Parser, LookupTXT
returned two strings in one record as two different records. This change
reverts back to concatenating multiple strings in a single
TXT record.

Updates golang#27763
Fixes golang#27886

Change-Id: Ice226fcb2be4be58853de34ed35b4627acb429ea
Reviewed-on: https://go-review.googlesource.com/136955
Reviewed-by: Ian Gudger <igudger@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Gudger <igudger@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 7b3b160323b56b357832549fbab7a60d27688ec1)
Reviewed-on: https://go-review.googlesource.com/138177
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>

* [release-branch.go1.11] encoding/json: fix UnmarshalTypeError without field and struct values

Updates golang#26444
Updates golang#27275
Fixes golang#27318

Change-Id: I9e8cbff79f7643ca8964c572c1a98172b6831730
GitHub-Last-Rev: 7eea215
GitHub-Pull-Request: golang#26719
Reviewed-on: https://go-review.googlesource.com/126897
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/138178
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

* [release-branch.go1.11] doc: document Go 1.11.1

Updates golang#27953

Change-Id: I2f1a55e15dc5737a5a06bd894c46b2c4705f338c
Reviewed-on: https://go-review.googlesource.com/138858
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit f99fc3a)
Reviewed-on: https://go-review.googlesource.com/138859
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

* [release-branch.go1.11] go1.11.1

Change-Id: I3cf3e57b11ad02b497276bae1864fc5ade8144b9
Reviewed-on: https://go-review.googlesource.com/138860
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

* [release-branch.go1.11] misc/wasm: add mention of polyfill for Edge support

Edge supports WebAssembly but not TextEncoder or TextDecoder.
This change adds a comment pointing to a polyfill that could
be used. The polyfill is not added by default, because we want to
let the user decide if/how to include the polyfill.

Fixes golang#27295

Change-Id: I375f58f2168665f549997b368428c398dfbbca1c
Reviewed-on: https://go-review.googlesource.com/139037
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit cfb603b0b5fb9c1e72be665b2d65743ddf18c779)
Reviewed-on: https://go-review.googlesource.com/139057
Reviewed-by: Richard Musiol <neelance@gmail.com>

* [release-branch.go1.11] cmd/compile: don't crash reporting misuse of shadowed built-in function

The existing implementation causes a compiler panic if a function parameter shadows a built-in function, and then calling that shadowed name.

Updates golang#27356
Fixes golang#27399

Change-Id: I1ffb6dc01e63c7f499e5f6f75f77ce2318f35bcd
Reviewed-on: https://go-review.googlesource.com/132876
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 4a095b8)
Reviewed-on: https://go-review.googlesource.com/c/139103
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] cmd/compile: fix type of OffPtr in some optimization rules

In some optimization rules the type of generated OffPtr was
incorrectly set to the type of the pointee, instead of the
pointer. When the OffPtr value is spilled, this may generate
a spill of the wrong type, e.g. a floating point spill of an
integer (pointer) value. On Wasm, this leads to invalid
bytecode.

Fixes golang#27961.

Change-Id: I5d464847eb900ed90794105c0013a1a7330756cc
Reviewed-on: https://go-review.googlesource.com/c/139257
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>
(cherry picked from commit c96e3bc)
Reviewed-on: https://go-review.googlesource.com/c/139104
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

* [release-branch.go1.11] cmd/go: don't mention -mod=release

The -mod=release flag is not supported, so this appears to be a
documentation mistake.

Updates golang#27354.
Fixes golang#27398.

Change-Id: I895e8d5b4918adcb1f605361773173f312fa7b65
GitHub-Last-Rev: 42bfe0c
GitHub-Pull-Request: golang#27358
Reviewed-on: https://go-review.googlesource.com/132116
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 014901c)
Reviewed-on: https://go-review.googlesource.com/c/139421
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

* [release-branch.go1.11] doc: update docs.html with new tour import path

As of golang.org/cl/141857 the import path has changed from
golang.org/x/tour/gotour to golang.org/x/tour

Change-Id: Ib54ab2e50188ef66c8a5c45136babfa49ad6934a
Reviewed-on: https://go-review.googlesource.com/c/141917
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 035f9e8)
Reviewed-on: https://go-review.googlesource.com/c/143617

* [release-branch.go1.11] cmd/go: ensure git attributes are set

This change disables the export-subst and export-ignore attributes when
creating zip files for modules. This is done to prevent the ziphash for
a given repo/revision from differing based on variables such as git
version or size of repo. The full rational for this change is detailed
here:

    golang#27153 (comment)

Fixes golang#28094

Change-Id: Ib33f525d91d2581fa0b5d26e70d29620c7e685e9
Reviewed-on: https://go-review.googlesource.com/c/135175
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-on: https://go-review.googlesource.com/c/141098
Reviewed-by: Andrew Bonventre <andybons@golang.org>

* [release-branch.go1.11] cmd/go, cmd/link: silence bogus Apple Xcode warning

Certain installations of Xcode are affected by a bug that causes
them to print an inconsequential link-time warning that looks like:

	ld: warning: text-based stub file /System/Library/Frameworks//Security.framework/Security.tbd and library file /System/Library/Frameworks//Security.framework/Security are out of sync. Falling back to library file for linking.

This has nothing to do with Go, and we've sent this repro case
to Apple:

	$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
	version: 10.0.0.0.1.1535735448
	$ clang --version
	Apple LLVM version 10.0.0 (clang-1000.10.44.2)
	Target: x86_64-apple-darwin17.7.0
	Thread model: posix
	InstalledDir: /Library/Developer/CommandLineTools/usr/bin
	$ cat > issue.c
	int main() { return 0; }
	^D
	$ clang issue.c -framework CoreFoundation
	ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
	$

Even if Apple does release a fixed Xcode, many people are seeing
this useless warning, and we might as well make it go away.

Fixes golang#26073.

Change-Id: Ifc17ba7da1f6b59e233c11ebdab7241cb6656324
Reviewed-on: https://go-review.googlesource.com/c/144112
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
(cherry picked from commit 66bb8dd)
Reviewed-on: https://go-review.googlesource.com/c/145458
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

* [release-branch.go1.11] internal/poll: advance file position in windows sendfile

Some versions of Windows (Windows 10 1803) do not set file
position after TransmitFile completes. So just use Seek
to set file position before returning from sendfile.

Fixes golang#27411

Change-Id: I7a49be10304b5db19dda707b13ac93d338aeb190
Reviewed-on: https://go-review.googlesource.com/131976
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Yasuhiro MATSUMOTO <mattn.jp@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/145779
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>

* [release-branch.go1.11] cmd/go/internal/modcmd: remove non-existent -dir flag

Updates golang#27243
Fixes golang#27498

Change-Id: If9230244938dabd03b9afaa6600310df8f97fe92
Reviewed-on: https://go-review.googlesource.com/131775
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 55ef446)
Reviewed-on: https://go-review.googlesource.com/c/146717
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

* [release-branch.go1.11] cmd/trace: don't drop sweep slice details

For sweep events, we used to modify the ViewerEvent returned from
ctx.emitSlice later in order to embed more details about the sweep
operation. The trick no longer works after the change
https://golang.org/cl/92375 and caused a regression.

ctx.emit method encodes the ViewerEvent, so any modification to the
ViewerEvent object after ctx.emit returns will not be reflected.

Refactor ctx.emitSlice, so ctx.makeSlice can be used when producing
slices for SWEEP. ctx.emit* methods are meant to truely emit
ViewerEvents.

Fixes golang#27717
Updates golang#27711

Change-Id: I0b733ebbbfd4facd8714db0535809ec3cab0833d
Reviewed-on: https://go-review.googlesource.com/135775
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit e57f24a)
Reviewed-on: https://go-review.googlesource.com/c/146698
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

* [release-branch.go1.11] database/sql: correctly report MaxIdleClosed stat

Previously the MaxIdleClosed counter was incremented when added
to the free connection list, rather then when it wasn't added
to the free connection list. Flip this logic to correct.

Fixes golang#28325

Change-Id: I405302c14fb985369dab48fbe845e5651afc4ccf
Reviewed-on: https://go-review.googlesource.com/c/138578
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 7db509e)
Reviewed-on: https://go-review.googlesource.com/c/146697
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>

* [release-branch.go1.11] go/types: use correct receiver types for embedded interface methods

Interface methods don't declare a receiver (it's implicit), but after
type-checking the respective *types.Func objects are marked as methods
by having a receiver. For interface methods, the receiver base type used
to be the interface that declared the method in the first place, even if
the method also appeared in other interfaces via embedding. A change in
the computation of method sets for interfaces for Go1.10 changed that
inadvertently, with the consequence that sometimes a method's receiver
type ended up being an interface into which the method was embedded.
The exact behavior also depended on file type-checking order, and because
files are sometimes sorted by name, the behavior depended on file names.

This didn't matter for type-checking (the typechecker doesn't need the
receiver), but it matters for clients, and for printing of methods.

This change fixes interface method receivers at the end of type-checking
when we have all relevant information.

Fixes golang#28249
Updates golang#28005

Change-Id: I96c120fb0e517d7f8a14b8530f0273674569d5ea
Reviewed-on: https://go-review.googlesource.com/c/141358
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-on: https://go-review.googlesource.com/c/146660
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

* [release-branch.go1.11] doc: document Go 1.10.5

Change-Id: I11adca150ab795607b832fb354a3e065655e1020
Reviewed-on: https://go-review.googlesource.com/c/147179
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 2764d5e)
Reviewed-on: https://go-review.googlesource.com/c/147181
Reviewed-by: Andrew Bonventre <andybons@golang.org>

* [release-branch.go1.11] doc: document Go 1.11.2

Change-Id: Iaff03911f1807d462f1966590626bd486807f53d
Reviewed-on: https://go-review.googlesource.com/c/147178
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit c5d78f5)
Reviewed-on: https://go-review.googlesource.com/c/147182
Reviewed-by: Andrew Bonventre <andybons@golang.org>

* [release-branch.go1.11] go1.11.2

Change-Id: Idd3527ba8f2329876cbca646aacd97739b9828f7
Reviewed-on: https://go-review.googlesource.com/c/147217
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

* [release-branch.go1.11] runtime: never call into race detector with retaken P

cgocall could previously invoke the race detector on an M whose P had
been retaken. The race detector would attempt to use the P-local state
from this stale P, racing with the thread that was actually wired to
that P. The result was memory corruption of ThreadSanitizer's internal
data structures that presented as hard-to-understand assertion failures
and segfaults.

Reorder cgocall so that it always acquires a P before invoking the race
detector, and add a test that stresses the interaction between cgo and
the race detector to protect against future bugs of this kind.

Fixes golang#28690.

Change-Id: Ide93f96a23490314d6647547140e0a412a97f0d4
Reviewed-on: https://go-review.googlesource.com/c/148717
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
(cherry picked from commit e496e61)
Reviewed-on: https://go-review.googlesource.com/c/148902
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] runtime: avoid arm64 8.1 atomics on Android

The kernel on some Samsung S9+ models reports support for arm64 8.1
atomics, but in reality only some of the cores support them. Go
programs scheduled to cores without support will crash with SIGILL.

This change unconditionally disables the optimization on Android.
A better fix is to precisely detect the offending chipset.

Fixes golang#28586

Change-Id: I35a1273e5660603824d30ebef2ce7e429241bf1f
Reviewed-on: https://go-review.googlesource.com/c/147377
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/149557
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

* [release-branch.go1.11] cmd/go: don't panic when go run is passed ... under nonexistent dir

Given a nonexistent directory above a wildcard:

    go run ./nonexistent/...

Print this error instead of panicking:

    go run: no packages loaded from ./nonexistent/...

Updates golang#28696.
Fixes golang#28725

Change-Id: Iaa3bc5c78b14ef858d931778e1bc55ca626c5571
GitHub-Last-Rev: bb1a804
GitHub-Pull-Request: golang#28703
Reviewed-on: https://go-review.googlesource.com/c/148821
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
(cherry picked from commit 529ea7c)
Reviewed-on: https://go-review.googlesource.com/c/149607
Run-TryBot: Ian Lance Taylor <iant@golang.org>

* [release-branch.go1.11] cmd/compile: don't deadcode eliminate labels

Dead-code eliminating labels is tricky because there might
be gotos that can still reach them.

Bug probably introduced with CL 91056

Fixes golang#28617

Change-Id: I6680465134e3486dcb658896f5172606cc51b104
Reviewed-on: https://go-review.googlesource.com/c/147817
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Iskander Sharipov <iskander.sharipov@intel.com>
Reviewed-on: https://go-review.googlesource.com/c/147857

* runtime: when using explicit argmap, also use arglen

When we set an explicit argmap, we may want only a prefix of that
argmap.  Argmap is set when the function is reflect.makeFuncStub or
reflect.methodValueCall. In this case, arglen specifies how much of
the args section is actually live. (It could be either all the args +
results, or just the args.)

Fixes golang#28752

Change-Id: Idf060607f15a298ac591016994e58e22f7f92d83
Reviewed-on: https://go-review.googlesource.com/c/149217
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit 0098f8a)
Reviewed-on: https://go-review.googlesource.com/c/149457

* [release-branch.go1.11] cmd/compile: reintroduce work-around for cyclic alias declarations

This change re-introduces (temporarily) a work-around for recursive
alias type declarations, originally in https://golang.org/cl/35831/
(intended as fix for golang#18640). The work-around was removed later
for a more comprehensive cycle detection check. That check
contained a subtle error which made the code appear to work,
while in fact creating incorrect types internally. See golang#25838
for details.

By re-introducing the original work-around, we eliminate problems
with many simple recursive type declarations involving aliases;
specifically cases such as golang#27232 and golang#27267. However, the more
general problem remains.

This CL also fixes the subtle error (incorrect variable use when
analyzing a type cycle) mentioned above and now issues a fatal
error with a reference to the relevant issue (rather than crashing
later during the compilation). While not great, this is better
than the current status. The long-term solution will need to
address these cycles (see golang#25838).

As a consequence, several old test cases are not accepted anymore
by the compiler since they happened to work accidentally only.
This CL disables parts or all code of those test cases. The issues
are: golang#18640, golang#23823, and golang#24939.

One of the new test cases (fixedbugs/issue27232.go) exposed a
go/types issue. The test case is excluded from the go/types test
suite and an issue was filed (golang#28576).

Updates golang#18640.
Updates golang#23823.
Updates golang#24939.
Updates golang#25838.
Updates golang#28576.

Fixes golang#27232.
Fixes golang#27267.
Fixes golang#27383.

Change-Id: I6c2d10da98bfc6f4f445c755fcaab17fc7b214c5
Reviewed-on: https://go-review.googlesource.com/c/147286
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit e630538)
Reviewed-on: https://go-review.googlesource.com/c/151339
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

* [release-branch.go1.11] cmd/compile/internal/gc: OMUL should be evaluated when using soft-float

When using soft-float, OMUL might be rewritten to function call
so we should ensure it was evaluated first.

Updates golang#28688
Fixes golang#28694

Change-Id: I30b87501782fff62d35151f394a1c22b0d490c6c
Reviewed-on: https://go-review.googlesource.com/c/148837
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit c92e73b)
Reviewed-on: https://go-review.googlesource.com/c/151342
Reviewed-by: Andrew Bonventre <andybons@golang.org>

* [release-branch.go1.11] go/types: avoid certain problems with recursive alias type declarations

It is possible to create certain recursive type declarations involving
alias types which cause the type-checker to produce an (invalid) type
for the alias because it is not yet available. By type-checking alias
declarations in a 2nd phase, the problem is mitigated a bit since it
requires more convoluted alias declarations for the problem to appear.

Also re-enable testing of fixedbugs/issue27232.go again (which was the
original cause for this change).

Updates golang#28576.
Fixes golang#28972.

Change-Id: If6f9656a95262e6575b01c4a003094d41551564b
Reviewed-on: https://go-review.googlesource.com/c/147597
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-on: https://go-review.googlesource.com/c/151500
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.