BUG: mismatched types C.uint32_t and C.uint on older gcc versions about libseccomp-golang

[pcmoore]

@thorduri I hope you don't mind, I went ahead and added some text to the README via ab55783, does this look okay to you?

[meihuabo]

package main

import (
    "fmt"
    "reflect"
)

/*
#include <stdlib.h>
#include <seccomp.h>
#define ARCH_BAD ~0
const uint32_t C_ARCH_BAD = ARCH_BAD;
*/
import "C"

func main() {
    fmt.Println(reflect.TypeOf(C.C_ARCH_BAD))
}

i run this code on different server and get different result：

result1:               main._Ctype_uint32_t

result1:               main._Ctype_uint

[meihuabo]

resolve it:
golang/go#12599
my C complier gcc(4.6.3) is too old

[mheon]

Glad to hear this was resolved - I was having difficulty replicating the failure. Probably worth adding something to the readme about GCC and Golang versions that we can build against.

[pcmoore]

I'm going to reopen this so we don't forget it, I agree with @mheon that we should document our version dependencies. @mheon or @meihuabo, do either of you want to draft patch for the readme?

[meihuabo]

I also agree with @mheon
I will try different gcc and go combination to find the minimum version to install libseccomp-golang

[pcmoore]

Great, thanks for the help!

[mheon]

The earliest version I've personally verified on is Ubuntu 14.04's Golang 1.2.1 and GCC 4.8.4. GCC <= 4.6 seems to cause the issue indicated here. Would be interesting to see if GCC 4.7.x works.

[meihuabo]

I've verified GCC 4.6.4 and it works
But I encountered som difficulties when setting up to GCC 4.6.x environment
still working on the environment

[thorduri]

Would a blurb like the following (on top of #14 -- I'm loathe to add it directly now) suffice to close this issue ?

* Installing the package

Using go get:

	$ go get github.com/seccomp/libseccomp-golang

For golang versions older then 1.2.1, and GCC versions older then 4.8.4 your milage may vary.

Adding a "supported" blurb is harder, as there are currently no tests for that (yet).

[pcmoore]

@mheon what do you think of @thorduri's suggestion?

[mheon]

@pcmoore Sounds fine here. I don't anticipate many people still on this combination, as even LTS distros like Debian and RHEL have moved past Go 1.2, but it's good to cover our bases.

[thorduri]

@mheon It has probably less to do with the go version, then the packaged / distributed libseccomp though.

I'll submit a PR with that blurb when #14 gets merged.

I'd love to see the PRs/Issues that are attached to the v2.3 milestone dealt with, and then see #4 implemented -- and maintaining "tagging" parity with libseccomp (I have a similar peeve with vendoring the package).

Anything I can do specifically to help with that ?

[pcmoore]

@thorduri I apologize that I'm not clearing the libseccomp issues/PRs very quickly, especially when it comes to the golang bindings. I'm hopeful that I will be able to spend more time on these as we get close to the end of the year, but at the moment the audit and SELinux kernel work is dominating my time.

Thanks for your interest and patches, I really do appreciate the help!

[thorduri]

@pcmoore No problem!

[pcmoore]

Based on the thumbs-up, I'm going to consider this resolved and close this issue. Thanks all!