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: #define macro error with upstream go #20125

Closed
tophj-ibm opened this issue Apr 25, 2017 · 10 comments
Closed

cmd/cgo: #define macro error with upstream go #20125

tophj-ibm opened this issue Apr 25, 2017 · 10 comments
Milestone

Comments

@tophj-ibm
Copy link

Hi, I've been testing docker with upstream go, and ever since this cgo patch
89ff0b1, I've been unable to build the docker binaries.

The problem looks cgo related and I've created a small test below that can reproduce the issue.

What version of Go are you using (go version)?

go 1.8.1 compiles without an error
upstream go since 89ff0b1 fails to compile

What operating system and processor architecture are you using (go env)?

Fails on x86_64 as well, is easily reproducible below as long as you have the right linux header or ran in a container.

GOARCH="ppc64le"
GOBIN=""
GOEXE=""
GOHOSTARCH="ppc64le"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_ppc64le"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build967771292=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

I was running docker CI with upstream go, but this should make the issue reproducible

package main

/*
#include <linux/fs.h>
struct fsxattr {
        __u32           fsx_xflags;
        __u32           fsx_extsize;
        __u32           fsx_nextents;
        __u32           fsx_projid;
        unsigned char   fsx_pad[12];
};
#ifndef FS_IOC_FSGETXATTR
#define FS_IOC_FSGETXATTR               _IOR ('X', 31, struct fsxattr)
#endif
*/
import "C"
import (
        "fmt"
)

func main() {
        fmt.Println("Hello, playground")
        fmt.Println(C.FS_IOC_FSGETXATTR)
        fmt.Println("done")
}

What did you expect to see?

Hello, playground
"somenumbers"
done

What did you see instead?

could not determine kind of name for C.FS_IOC_FSGETXATTR

Any ideas would be helpful, Thanks!

@bradfitz bradfitz added this to the Go1.9 milestone Apr 25, 2017
@ianlancetaylor
Copy link
Contributor

Referenced CL is https://golang.org/cl/35511.

CC @hirochachacha

@ianlancetaylor
Copy link
Contributor

The problem is because GCC is generating this:

In file included from /usr/include/x86_64-linux-gnu/asm/ioctl.h:1:0,
                 from /usr/include/linux/ioctl.h:4,
                 from /usr/include/linux/fs.h:10,
                 from /home/iant/foo8.go:4:
not-str-lit: In function '__cgo_f_1_5':
/home/iant/foo8.go:13:63: error: invalid initializer
 #define FS_IOC_FSGETXATTR               _IOR ('X', 31, struct fsxattr)
                                                               ^
not-str-lit:1:51: note: in expansion of macro 'FS_IOC_FSGETXATTR'

cgo is looking for an "error" on line not-str-lit:1, but it only sees a "note".

@hirochachacha
Copy link
Contributor

I will see this within couple of days if the issue hasn't been closed in that time. Thanks.

@gopherbot
Copy link

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

@hirochachacha
Copy link
Contributor

@ianlancetaylor I tried to solve this by finalizing #define values. (see the above patch)
We can also solve this by giving "-ftrack-macro-expansion=0" to gcc.
The option is not supported on clang nor old gcc (~4.6?)
I'm not sure which is preferable. What do you think?

@ianlancetaylor
Copy link
Contributor

As noted on the CL the patch makes me nervous.

What happens with clang or older GCC today? Do they succeed or fail on this test?

@hirochachacha
Copy link
Contributor

Oh, the email notification was delayed.

What happens with clang or older GCC today? Do they succeed or fail on this test?

It succeeds with clang. clang doesn't track macro expansions in error messages, as far as I can see.
I didn't test with older GCC, but I assume it will succeed too. See #5118.

@gopherbot
Copy link

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

@ianlancetaylor
Copy link
Contributor

@hirochachacha I sent https://golang.org/cl/44290 as an alternate approach that fixes this bug. It doesn't address all the cases that your CL handles, but I feel more confident about its portability and correctness. Let me know what you think.

@tophj-ibm
Copy link
Author

thanks guys! I just tested it and works 🎉

@golang golang locked and limited conversation to collaborators Jun 14, 2018
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

5 participants