go+cgo+gccgo status: looking good
Albert Strasheim
With goprotobuf compiling with gccgo, I've tried the rest of our
codebase. go+cgo+gccgo is close to handling all 160k lines of it!
A few comments:
A few bits in syscall seem to be missing:
error: reference to undefined identifier ‘syscall.MS_NOEXEC’
error: reference to undefined identifier ‘syscall.MS_NOATIME’
error: reference to undefined identifier ‘syscall.MS_SYNCHRONOUS’
error: reference to undefined identifier ‘syscall.Fallocate’
error: reference to undefined identifier ‘syscall.Statfs_t’
error: reference to undefined identifier ‘syscall.Statfs’
runtime.Callers is missing in gccgo. We just use it for some logging,
so it's not a big deal. Is the idea that gccgo will support it or not?
What is the procedure for building the Go subrepos with gccgo? We need
go.crypto and go.net.
We have a package that compiles with 6g and cgo but not with gccgo and cgo:
$ go install .
$ GC=gccgo go install .
# iconv
iconv.go:33:2: error: unknown type name ‘int32_t’
iconv.go:45:2: error: unknown type name ‘int32_t’
iconv.go:47:72: error: expected declaration specifiers or ‘...’ before ‘%’ token
iconv.go:47:80: error: expected declaration specifiers or ‘...’ before ‘%’ token
iconv.go:47:88: error: expected declaration specifiers or ‘...’ before ‘%’ token
iconv.go:47:96: error: expected declaration specifiers or ‘...’ before ‘%’ token
iconv.go:57:2: error: unknown type name ‘int32_t’
iconv.go:59:70: error: expected declaration specifiers or ‘...’ before ‘%’ token
iconv.go:59:78: error: expected declaration specifiers or ‘...’ before
‘%’ token\
This is with gccgo from gcc Git as of a few seconds ago and Go from
tip with CL 5650066 applied. Source attached.
Thanks for all the work so far!
Regards
Albert
Rémy Oudompheng
> What is the procedure for building the Go subrepos with gccgo? We need
> go.crypto and go.net.
Here I have already "go get" (go got?) them and
GC=gccgo go install -v code.google.com/p/go.crypto/...
compiles them as expected.
R�my.
Rémy Oudompheng
> iconv.go:33:2: error: unknown type name ‘int32_t’
> iconv.go:45:2: error: unknown type name ‘int32_t’
> iconv.go:47:72: error: expected declaration specifiers or ‘...’ before ‘%’ token
> iconv.go:47:80: error: expected declaration specifiers or ‘...’ before ‘%’ token
> iconv.go:47:88: error: expected declaration specifiers or ‘...’ before ‘%’ token
> iconv.go:47:96: error: expected declaration specifiers or ‘...’ before ‘%’ token
> iconv.go:57:2: error: unknown type name ‘int32_t’
> iconv.go:59:70: error: expected declaration specifiers or ‘...’ before ‘%’ token
> iconv.go:59:78: error: expected declaration specifiers or ‘...’ before
> ‘%’ token\
>
> This is with gccgo from gcc Git as of a few seconds ago and Go from
> tip with CL 5650066 applied. Source attached.
I've updated 5650066 to fix.
Rémy.
Rémy Oudompheng
> Thanks.
>
> I'm trying to debug a strange link error with gccgo so I did:
> GC=gccgo go install -x > build.sh
> with the idea of executing build.sh to step through the build to debug it.
>
> The first thing I had to change was to add:
> GOBIN=$GOROOT/bin
> to the top of the file.
>
> build.sh ends up with commands like:
> gccgo -o $WORK/cmd/foo/_obj/a.out $WORK/cmd/foo/_obj/main.o -Wl,-( -Wl,-)
> which doesn't seem to work with bash:
>
> build.sh: line 41: syntax error near unexpected token `('
>
> It seems the brackets need to be escaped:
>
> gccgo -o $WORK/cmd/foo/_obj/a.out $WORK/cmd/foo/_obj/main.o -Wl,-\( -Wl,-\)
You're right. I'm not sure how it is guaranteed that go build -n -x
output can be readily used as a shell script.
> Another question (I'll stop soon): have you looked at gccgo support
> for go test yet?
As far as I know, go test works with gccgo for the packages I could build.
Rémy.
Albert Strasheim
On Sun, Feb 12, 2012 at 3:04 PM, Rémy Oudompheng
<remyoud...@gmail.com> wrote:
>> It seems the brackets need to be escaped:
>> gccgo -o $WORK/cmd/foo/_obj/a.out $WORK/cmd/foo/_obj/main.o -Wl,-\( -Wl,-\)
> You're right. I'm not sure how it is guaranteed that go build -n -x
> output can be readily used as a shell script.
Should I file an issue?
>> Another question (I'll stop soon): have you looked at gccgo support
>> for go test yet?
> As far as I know, go test works with gccgo for the packages I could build.
I tried a very basic package, but no luck:
$ GC=gccgo go test -x uuid
WORK=/tmp/go-build801793783
mkdir -p $WORK/uuid/_test/
cd /home/alberts/foo/src/uuid
gccgo -I $WORK -c -l -g -fgo-prefix=fake_uuid -o
$WORK/uuid/_test/uuid.o ./uuid.go ./uuid_test.go
ar cru $WORK/uuid/_test/libuuid.a $WORK/uuid/_test/uuid.o
cd $WORK/uuid/_test
gccgo -I . -I $WORK -c -l -g -o ./main.o ./_testmain.go
ar cru ./main.a ./main.o
gccgo -o ./uuid.test ./main.o -Wl,-( -Wl,-)
# gccgo -o ./uuid.test ./main.o -Wl,-( -Wl,-)
gccgo: error: : No such file or directory
$WORK/uuid/_test/uuid.test
FAIL uuid [build failed]
Regards
Albert
Rémy Oudompheng
>
> $ GC=gccgo go test -x uuid
> WORK=/tmp/go-build801793783
> mkdir -p $WORK/uuid/_test/
> cd /home/alberts/foo/src/uuid
> gccgo -I $WORK -c -l -g -fgo-prefix=fake_uuid -o
> $WORK/uuid/_test/uuid.o ./uuid.go ./uuid_test.go
> ar cru $WORK/uuid/_test/libuuid.a $WORK/uuid/_test/uuid.o
> cd $WORK/uuid/_test
> gccgo -I . -I $WORK -c -l -g -o ./main.o ./_testmain.go
> ar cru ./main.a ./main.o
> gccgo -o ./uuid.test ./main.o -Wl,-( -Wl,-)
> # gccgo -o ./uuid.test ./main.o -Wl,-( -Wl,-)
> gccgo: error: : No such file or directory
> $WORK/uuid/_test/uuid.test
> FAIL uuid [build failed]
>
That's caused by the a.target -> a.p.target patch. The current version
of the go tool works correctly. I have not thought about a better way
this part could be done.
Rémy.
Albert Strasheim
On Sun, Feb 12, 2012 at 3:16 PM, Rémy Oudompheng
<remyoud...@gmail.com> wrote:
> On 2012/2/12 Albert Strasheim <ful...@gmail.com> wrote:
>> I tried a very basic package, but no luck:
> That's caused by the a.target -> a.p.target patch. The current version
> of the go tool works correctly. I have not thought about a better way
> this part could be done.
Thanks. Without the patch I can now build some tests!
I am trying to get the point where I can run gcov/lcov on the tests I
build with gccgo. The last hurdle I'm aware of is support for an
LDFLAGS environment variable in the go tool:
http://code.google.com/p/go/issues/detail?id=2996
Almost there...
Regards
Albert
Ian Lance Taylor
> A few bits in syscall seem to be missing:
>
> error: reference to undefined identifier ‘syscall.MS_NOEXEC’
> error: reference to undefined identifier ‘syscall.MS_NOATIME’
> error: reference to undefined identifier ‘syscall.MS_SYNCHRONOUS’
> error: reference to undefined identifier ‘syscall.Fallocate’
> error: reference to undefined identifier ‘syscall.Statfs_t’
> error: reference to undefined identifier ‘syscall.Statfs’
Can you open an issue for these? I think they just need a bit of work
in mksysinfo to define the required constants and structures. Thanks.
> runtime.Callers is missing in gccgo. We just use it for some logging,
> so it's not a big deal. Is the idea that gccgo will support it or not?
The intent is to support it. To be precise I think supporting
runtime.Callers is fairly easy. The hard part is supporting FuncForPC,
and supporting the file and line return values of runtime.Caller.
In the gccgo world those will require doing something like opening
argv[0] (or /proc/self/exe) and finding and parsing the DWARF debugging
information. This approach does mean that runtime.Caller and FuncForPC
will only work if you compile with -g, but, under the assumption that
most people do that, I don't particularly want to grow every Go program
with another copy of the mapping from PC to file/line.
I don't know of a convenient library to use to parse the DWARF
information for this, so this will probably require adding line number
support to the debug/dwarf package.
Running gccgo on Windows (which doesn't work today anyhow) will require
a slightly different approach since my understanding is that Windows
binaries typically don't have DWARF debug info.
Ian