gccgo vs go

[ph...@bolthole.com]

So... I  have gcc7.3.0 with --enable-languages=go, successfully compiled for solaris 11 sparc.

I would like to have a better understanding of what I should expect to work, and what not to work, and why.

(and how I can potentially fix my environment)

My current understanding is that my "go" executable works for things like "go get", blah blah, 

but not for actually running any other go code.

For example, I can do this currently:

  $ go help

  Go is a tool for managing Go source code.

  Usage:

  blah blah blah

In contrast, "gccgo", CAN actually compile go code. 
And after all, gcc used gccgo, to compile the included "go" executable. successfully!

and I can run super trivial stuff such as:

$ cat hello.go

package main

import "fmt"

func main(){

        fmt.Println("Hellow me")

}

its-zones1$ gccgo hello.go -R/usr/local/gcc/lib

its-zones1$ ./a.out

Hellow me

Yet when I attempt to use it to compile anything non-trvial, i get errors such as

package bufio: unrecognized import path "bufio" (import path does not begin with hostname)

despite the fact that there is a presumably good file,

/usr/local/gcc/lib/go/7.3.0/sparc-sun-solaris2.11/bufio.gox

and all the rest of the expected things.

as mentioned, the "go" executable compiled and runs mostly fine. 

So presumably, there should be SOME way I can get to use at least the more portable parts of the

go runtime.

What am I missing?

[Ian Lance Taylor]

On Mon, Apr 23, 2018 at 5:12 PM, <ph...@bolthole.com> wrote:
>
> So... I have gcc7.3.0 with --enable-languages=go, successfully compiled for
> solaris 11 sparc.
>
> I would like to have a better understanding of what I should expect to work,
> and what not to work, and why.
>
> (and how I can potentially fix my environment)
>
>
> My current understanding is that my "go" executable works for things like
> "go get", blah blah,
> but not for actually running any other go code.

That turns out not to be the case. The `go` executable installed by a
gccgo build can run `go build`, `go install`, `go run`, etc., and they
should all work as expected.

Ian

[Philip Brown]

On Monday, April 23, 2018 at 9:21:54 PM UTC-7, Ian Lance Taylor wrote:

That turns out not to be the case.  The `go` executable installed by a
gccgo build can run `go build`, `go install`, `go run`, etc., and they
should all work as expected.

well then I hope you can give me some ideas for troubleshooting.

Becuase it doesnt work properly on solaris sparc (unsupported) OR solaris x86 (supposedly supported)

 

[Ian Lance Taylor]

What, precisely, did you do? What, precisely, happened? What did you
expect to happen instead?

Ian

[Philip Brown]

On Monday, April 23, 2018 at 9:35:37 PM UTC-7, Ian Lance Taylor wrote:

What, precisely, did you do?  What, precisely, happened?  What did you
expect to happen instead?

okay, for the trivial "hello world" case I posted earlier.

SOLARIS 11 X86

  (it should be noted that for some reason, the executable is 64bit??)

/usr/local/gcc/bin/go run hello.go

hello.go:2:8: cannot find package "fmt" in any of:

        /usr/local/gcc/src/fmt (from $GOROOT)

       (home)/go/src/fmt (from $GOPATH)

package main

        imports runtime: cannot find package "runtime" in any of:

        /usr/local/gcc/src/runtime (from $GOROOT)

        (home)/go/src/runtime (from $GOPATH)

 

SOLARIS 11 SPARC

  (interestingly, THIS executable is 32bit)

 .. actually, the same error for this trivial case.

other programs, it gives different errors.

but lets start with the trivial case.

[Ian Lance Taylor]

Can you describe how you built and installed gccgo? Are there any
directories matching /usr/local/gcc/*/go, and what is in those
directories? What is the output of `/usr/local/gcc/bin/go env`? What
is the output of `/usr/local/gcc/bin/gccgo hello.go`? Thanks.

Ian

[Philip Brown]

On Mon, Apr 23, 2018 at 10:48 PM, Ian Lance Taylor <ia...@golang.org> wrote:
>
>
> Can you describe how you built and installed gccgo? Are there any
> directories matching /usr/local/gcc/*/go, and what is in those
> directories? What is the output of `/usr/local/gcc/bin/go env`? What
> is the output of `/usr/local/gcc/bin/gccgo hello.go`? Thanks.

built with gcc5.4 i believe.

the following output is all from my x86 host


$ ls -ld /usr/local/gcc/*/go
-rwxr-xr-x 1 root bin 2476880 Apr 22 16:23 /usr/local/gcc/bin/go
drwxr-xr-x 3 root bin 3 Apr 22 16:24 /usr/local/gcc/lib/go

/usr/local/gcc/bin/go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="solaris"
GOOS="solaris"
GOPATH="$HOME/go"
GORACE=""
GOROOT="/usr/local/gcc"
GOTOOLDIR="/usr/local/gcc/libexec/gcc/x86_64-pc-solaris2.11/7.3.0"
GCCGO="/usr/local/gcc/bin/gccgo"
CC="/usr/local/gcc/bin/gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=/tmp/go-build477818900=/tmp/go-build
-gno-record-gcc-switches"
CXX="/usr/local/gcc/bin/g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"


and as for the gccgo output I believe I posted it previously, but for
convenience here it is again:
$ /usr/local/gcc/bin/gccgo hello.go -R/usr/local/gcc/lib/amd64
$ ./a.out
Hellow me

and for bonus points:


$ ldd a.out
libgo.so.11 => /usr/local/gcc/lib/amd64/libgo.so.11
libm.so.2 => /lib/64/libm.so.2
libgcc_s.so.1 => /usr/local/gcc/lib/amd64/libgcc_s.so.1
libc.so.1 => /lib/64/libc.so.1
libpthread.so.1 => /lib/64/libpthread.so.1
libsocket.so.1 => /lib/64/libsocket.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libsendfile.so.1 => /lib/64/libsendfile.so.1
libgcc_s.so.1 => /usr/lib/64/libgcc_s.so.1
libmp.so.2 => /lib/64/libmp.so.2
libucrypto.so.1 => /lib/64/libucrypto.so.1
libelf.so.1 => /lib/64/libelf.so.1
libcryptoutil.so.1 => /lib/64/libcryptoutil.so.1
libz.so.1 => /lib/64/libz.so.1

$ ldd /usr/local/gcc/bin/go
libsocket.so.1 => /lib/64/libsocket.so.1
libnsl.so.1 => /lib/64/libnsl.so.1
libgo.so.11 => /usr/local/gcc/lib/amd64/libgo.so.11
libm.so.2 => /lib/64/libm.so.2
libc.so.1 => /lib/64/libc.so.1
libmp.so.2 => /lib/64/libmp.so.2
libucrypto.so.1 => /lib/64/libucrypto.so.1
libpthread.so.1 => /lib/64/libpthread.so.1
libsendfile.so.1 => /lib/64/libsendfile.so.1
libgcc_s.so.1 => /usr/local/gcc/lib/amd64/libgcc_s.so.1
libelf.so.1 => /lib/64/libelf.so.1
libcryptoutil.so.1 => /lib/64/libcryptoutil.so.1
libz.so.1 => /lib/64/libz.so.1

[Philip Brown]

oops, i forgot full configure options.

options="--with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/bin/ld --withou
t-gnu-ld --with-gmp-include=/usr/include/gmp --with-gmp-lib=/usr/lib --with-mpfr
-include=/usr/include/mpfr --with-mpfr-lib=/usr/lib --with-mpfr=/usr/include --w
ith-mpc=/usr/include --disable-nls --disable-libquadmath --disable-libssp --disa
ble-lto --disable-libgomp --with-build-time-tools=/usr/sfw"

multilib="--enable-multilib"
shared="--enable-shared"
languages="--enable-languages=go,c"

export OBJCOPY=gobjcopy

../configure --prefix=/usr/local/gcc "$languages" $options $shared $static $mult
ilib "$version" && gmake -j 2

[Ian Lance Taylor]

Thanks for the info. What is the output of `go version`?

I'm not sure what is happening here. I have not been able to recreate
it. I built and installed a fresh GCC 7 build, and it is working fine
for me.

It looks as though your go tool is somehow failing to recognize that
"fmt" is a package in the standard library. In your gccgo build
directory, there should be a file TARGET/libgo/zstdpkglist.go. That
file contains a map composite literal that lists all the standard
library packages. In my build it looks like this (this is
abbreviated):

package main

var stdpkg = map[string]bool{
"archive/tar": true,
...
"fmt": true,
...
}

What does it look like in your build directory?

Depending on the version of sed that you are using, you may need to
apply https://golang.org/cl/37940 to your sources. That patch is in
the upcoming GCC 8 but it may not be in GCC 7.

Ian

[Philip Brown]

okay, so..

according to config.log, it correctly detected and use GNU sed on
solaris, as /usr/bin/gsed.
$ gsed --version
GNU sed version 4.2.1


$ go version
go version go1.8.3 gccgo (GCC) 7.3.0 solaris/amd64

the file you mentioned, zstdpglist.go, is gutted in content.

var stdpkg = map[string]bool{
}

applying the patch you mentioned, did get it populated.
(after I hand removed the file)

and then a top level gmake rebuild it relatively fast, and hey.. it works!!
on x86 so far, at least.

Thanks :)

$ go run hello.go
Hellow me

[Philip Brown]

More fun.

first off, some good news: the sparc version works now as well!

I can successfully do

go get golang.org/x/text

on both solaris 11 x86, AND sparc!

bad news:

while

go get golang.org/x/net/html

works on sparc.. it fails on x86 now, with

$ go get golang.org/x/net/html

fatal error: unexpected signal during runtime execution

[signal SIGSEGV: segmentation violation code=1 addr=18446744073709551613 pc=18446604434604646664]

goroutine 19 [syscall]:

fatal error: unexpected signal during runtime execution

panic during panic

[signal SIGSEGV: segmentation violation code=1 addr=18446744073709551613 pc=18446604434604646664]

goroutine 19 [syscall]:

fatal error: unexpected signal during runtime execution

stack trace unavailable

Ironically, I suspect this is because x86 is "supported", so has syscall hooks.. which fail.. while sparc doesnt.. so 

it doesnt crash there, because it doesnt follow the same code? :)
Just a guess.

WAIT..

but...

If i then use "real go".. on x86,  it makes gccgo work afterwards as well? WHAT?

$ /opt/go1.10/bin/go get golang.org/x/net/html

$ go get golang.org/x/net/html

$

and oddly, when I attempt to run go under truss, to find out what its doing differently..then it fails again anyway.

$ go get golang.org/x/net/html

$ go get golang.org/x/net/html

$ go get golang.org/x/net/html

$ truss -t open -f -o /tmp/truss go get golang.org/x/net/html

fatal error: unexpected signal during runtime execution

[signal SIGSEGV: segmentation violation code=1 addr=18446744073709551613 pc=18446604434604646664]

goroutine 19 [syscall]:

fatal error: unexpected signal during runtime execution

panic during panic

[signal SIGSEGV: segmentation violation code=1 addr=18446744073709551613 pc=18446604434604646664]

goroutine 19 [syscall]:

fatal error: unexpected signal during runtime execution

stack trace unavailable

$ go get golang.org/x/net/html

$

[Philip Brown]

there may be some kind of race condition issue in sol x86 gccgo then.

I just retry'd a get, and it eventually works.

This ALSO happens when I try to run tests. what?

$ go get golang.org/x/image/bmp

fatal error: unexpected signal during runtime execution

[signal SIGSEGV: segmentation violation code=1 addr=18446744073709551613 pc=18446604434604646664]

goroutine 19 [syscall]:

fatal error: unexpected signal during runtime execution

panic during panic

[signal SIGSEGV: segmentation violation code=1 addr=18446744073709551613 pc=18446604434604646664]

goroutine 19 [syscall]:

fatal error: unexpected signal during runtime execution

stack trace unavailable

$ go get golang.org/x/image/bmp

fatal error: unexpected signal during runtime execution

[signal SIGSEGV: segmentation violation code=1 addr=18446744073709551613 pc=18446604434604646664]

goroutine 19 [syscall]:

fatal error: unexpected signal during runtime execution

panic during panic

[signal SIGSEGV: segmentation violation code=1 addr=18446744073709551613 pc=18446604434604646664]

goroutine 19 [syscall]:

fatal error: unexpected signal during runtime execution

stack trace unavailable

$ go get golang.org/x/image/bmp

$ go get golang.org/x/image/bmp

and now to test..

$ cd go/src

$ cd golang.org/x/image/bmp/

$ ls

reader.go       reader_test.go  writer.go       writer_test.go

$ which go

/usr/local/gcc/bin/go

$ echo $PATH

/usr/local/gcc/bin:/usr/bin:/usr/ccs/bin:/usr/sfw/bin:/usr/sbin

$ go test

fatal error: unexpected signal during runtime execution

[signal SIGSEGV: segmentation violation code=1 addr=18446604434615125009 pc=18446604434615132424]

goroutine 20 [running]:

fatal error: unexpected signal during runtime execution

panic during panic

[signal SIGSEGV: segmentation violation code=1 addr=18446604434615125009 pc=18446604434615132424]

goroutine 20 [running]:

fatal error: unexpected signal during runtime execution

stack trace unavailable

exit status 4

FAIL    golang.org/x/image/bmp  0.159s

$ go test

fatal error: unexpected signal during runtime execution

[signal SIGSEGV: segmentation violation code=1 addr=18446744073709551613 pc=18446604434604646664]

goroutine 19 [syscall]:

fatal error: unexpected signal during runtime execution

panic during panic

[signal SIGSEGV: segmentation violation code=1 addr=18446744073709551613 pc=18446604434604646664]

goroutine 19 [syscall]:

fatal error: unexpected signal during runtime execution

stack trace unavailable

$ go test

PASS

ok      golang.org/x/image/bmp  0.172s

$