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

Comments

@tophj-ibm
Copy link

commented Apr 25, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2017

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2017

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

@gopherbot

This comment has been minimized.

Copy link

commented Apr 27, 2017

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

@hirochachacha

This comment has been minimized.

Copy link
Contributor

commented May 24, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented May 24, 2017

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

This comment has been minimized.

Copy link
Contributor

commented May 24, 2017

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

This comment has been minimized.

Copy link

commented May 25, 2017

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

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented May 25, 2017

@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.

@gopherbot gopherbot closed this in dcaac4b Jun 14, 2017

@tophj-ibm

This comment has been minimized.

Copy link
Author

commented Jun 14, 2017

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
5 participants
You can’t perform that action at this time.