Go: gc / gccgo

Может ещё быть разница в cgo, хотя не уверен.

Была не полная реализация стандартной библиотеки. Ну и у gcc результат от libgo на 15мб зависит.

http://blog.golang.org/gccgo-in-gcc-471

Технических различий не так и много, да

http://blog.golang.org/gccgo-in-gcc-471

Благодарен.

В последней версии результат стал более ожидаемым, но не могу судить, знаком лишь поверхностно.

Помнится были проблемы со сборщиком (н.з. в 4.7.x это пофиксили) и что-то с гоуротинами, что? Как с этим сейчас?

Если я правильно ошибаюсь, проблема в том, что с помощью ld что трудно организовать отдельный стэк для каждой горутины. Поэтому каждой выделяется большой кусок памяти под стек, но если он переполняется, происходит неопределённое поведение.

Решением является переход на GNU gold. Он умеет увеличивать стек при входе в функцию.

Может ещё быть разница в cgo, хотя не уверен.

По-моему, теперь cgo поддерживает gcc, но я сам ещё не пробовал cgo под gcc.

По крайней мере на оф. сайте все ещё красуется:

Cgo does not yet work with gccgo.

После

go build -compiler gccgo test.go

Вот пишут:
https://code.google.com/p/go/issues/detail?id=2313

Кроме того, в том баге, где кто-то жаловался, что в GCCGO 4.8.2 func — больше не указатель на функцию, Иан Ланс Тейлор говорил, что должно уже работать и обещал починить документацию.

В debian testing на днях пришёл 4.8.2, под ним и пробовал.

All the tests in misc/cgo pass with gccgo, so I'm going to close this.

Если б он ещё и поконкретней с версией был.

И вопрос, можно ли напрямую gccgo собирать (и если да, как), а то:

gccgo -o test test.go 
test.go:7:9: error: import file "C" not found
 import "C"
         ^
test.go:11:11: error: reference to undefined name "C"
     cs := C.CString(s)
           ^
...

Хм... вот сейчас проверил на GCC 4.8.2:

package main

//#include <stdio.h>
import "C"

func main() {
	str := "Hello, world!\n"
	for _, r := range str {
                //Во избежание проблем с const
		C.putchar(C.int(r))
	}
}

Выполняем:

$ go build -compiler gccgo cgotest.go
<исследуем cgotest при помощи readelf, убеждаемся, что он собран с помощью GCC>
$ ./cgotest
Hello, world!

И вопрос, можно ли напрямую gccgo собирать (и если да, как)

Как-то, безусловно, можно, но для этого надо разобраться, как работает go (утилита сборки). Просто скормить исходник компилятору определённо не получится, компиляция будет многоэтапная. Можно вызвать «go tool cgo -gccgo=true исходник.go», она сделает папку «_obj», можно в ней копаться.

Значит, в Дебиане что-то не так.

Зависимости только от gcc:

$ ldd cgotest
	linux-vdso.so.1 (0x00007fff68dfe000)
	libgo.so.4 => /usr/lib/x86_64-linux-gnu/libgo.so.4 (0x00007fc279a3f000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc279822000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc279524000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc27930e000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc278f61000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc27a79b000)

Значит, в Дебиане что-то не так.
Зависимости только от gcc

А что не так? У меня такие же зависимости. А какие ещё должны быть?