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

cmd/cgo: "could not determine kind of name" with Xcode 5 #6612

Closed
james4k opened this issue Oct 17, 2013 · 4 comments
Closed

cmd/cgo: "could not determine kind of name" with Xcode 5 #6612

james4k opened this issue Oct 17, 2013 · 4 comments
Milestone

Comments

@james4k
Copy link
Contributor

james4k commented Oct 17, 2013

$ go build
# _/Users/jamesgray/proj/term4k/wat
could not determine kind of name for C.saywat

$ cat main.go
package wat
 
// void hrrr() {}
// #define hrr hrrr
// #define saywat hrr
import "C"
 
func uhh() {
        C.saywat()
}

$ go version
go version devel +9620ff603344 Thu Oct 17 11:57:48 2013 -0700 darwin/amd64

$ clang -v
Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix


Appears to be related to the fix for http://golang.org/issue/6128
(https://golang.org/cl/14702043). With this in mind, please look at the tail of
the outputs that follow, and note that the lack of output for the name seems to be the
root of this error.

Output for `go tool cgo -debug-gcc main.go` (clang 5.0):
https://gist.github.com/james4k/7031919#file-cgo-debug-gcc

Output for debug-gcc with clang 4.2:
https://gist.github.com/kisielk/7032410#file-4-2output-txt-L458
@james4k
Copy link
Contributor Author

james4k commented Oct 17, 2013

Comment 1:

Oh, and something I didn't make clear is that this builds successfully with clang 4.2.

@james4k
Copy link
Contributor Author

james4k commented Oct 17, 2013

Comment 2:

A possible fix: https://golang.org/cl/14816043

@rsc
Copy link
Contributor

rsc commented Oct 18, 2013

Comment 3:

This issue was closed by revision 06ad3b2.

Status changed to Fixed.

@adg
Copy link
Contributor

adg commented Nov 1, 2013

Comment 4:

This issue was closed by revision 2acdaa9fe432.

@rsc rsc added this to the Go1.2 milestone Apr 14, 2015
@rsc rsc removed the go1.2maybe label Apr 14, 2015
adg added a commit that referenced this issue May 11, 2015
…t to analyze C names

««« CL 15070043 / 90a628ac54ed
cmd/cgo: stop using compiler error message text to analyze C names

The old approach to determining whether "name" was a type, constant,
or expression was to compile the C program

        name;

and scan the errors and warnings generated by the compiler.
This requires looking for specific substrings in the errors and warnings,
which ties the implementation to specific compiler versions.
As compilers change their errors or drop warnings, cgo breaks.
This happens slowly but it does happen.
Clang in particular (now required on OS X) has a significant churn rate.

The new approach compiles a slightly more complex program
that is either valid C or not valid C depending on what kind of
thing "name" is. It uses only the presence or absence of an error
message on a particular line, not the error text itself. The program is:

        // error if and only if name is undeclared
        void f1(void) { typeof(name) *x; }

        // error if and only if name is not a type
        void f2(void) { name *x; }

        // error if and only if name is not an integer constant
        void f3(void) { enum { x = (name)*1 }; }

I had not been planning to do this until Go 1.3, because it is a
non-trivial change, but it fixes a real Xcode 5 problem in Go 1.2,
and the new code is easier to understand than the old code.
It should be significantly more robust.

Fixes #6596.
Fixes #6612.

R=golang-dev, r, james, iant
CC=golang-dev
https://golang.org/cl/15070043
»»»

R=golang-dev
CC=golang-dev
https://golang.org/cl/20060044
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants