инструменты Go (установка и использование)

[Olej]

Известно, что существуют 2 линии инструментария программирования на языке Go: а). базовый прект GoLang (который инициирован Google) и б). проект по включению языка Go в число поддерживаемых компилятором GCC ... более интегрированный со средой Linux.

Чем кто из них лучше-хуже - это любопытный вопрос ... но на будущее.
Есть ещё много мелких интересных деталей относительно 2-х реализаций.

Во всех предыдущих версиях Go (<=1.4) обе эти реализации можно было установить (из стандартных репозитариев!) параллельно и выполнять тот или другой по необходимости, сравнивать...

Но вот устанавливал я Go в Fedora 23 (RFR):

Код: Выделить всё

[olej@localhost ~]$ dnf info golang
Последняя проверка окончания срока действия метаданных: 20 days, 1:25:06 назад, Sun May  1 15:47:26 2016.
Доступные пакеты
Имя         : golang
Архитектура : x86_64
Эпоха       : 0
Версия      : 1.5.3
Релиз       : 1.fc23
Размер      : 1.2 M
Репозиторий : updates
Краткое опи : The Go Programming Language
URL         : http://golang.org/
Лицензия    : BSD and Public Domain
Описание    : The Go Programming Language.

Код: Выделить всё

[olej@localhost ~]$ sudo dnf install golang
...
Установлено:
  go-srpm-macros.noarch 2-3.fc23      golang.x86_64 1.5.4-1.fc23      golang-bin.x86_64 1.5.4-1.fc23      golang-src.noarch 1.5.4-1.fc23

Код: Выделить всё

[olej@dell GoBook]$ go build gopl.io/ch1/helloworld
[olej@dell GoBook]$ ./helloworld
Hello, 世界

Всё путём!
Но если теперь доустановить Go из проекта GCC:

Код: Выделить всё

[olej@dell GoBook]$ sudo dnf install gcc-go
...
Установлено:
  gcc-go.x86_64 5.3.1-6.fc23                libgo.x86_64 5.3.1-6.fc23                libgo-devel.x86_64 5.3.1-6.fc23
[olej@dell GoBook]$ gccgo --version
gccgo (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
Copyright (C) 2015 Free Software Foundation, Inc.
Это свободно распространяемое программное обеспечение. Условия копирования
приведены в исходных текстах. Без гарантии каких-либо качеств, включая
коммерческую ценность и применимость для каких-либо целей.

Всё ОК!

Код: Выделить всё

[olej@dell tasks]$ go build -compiler gccgo hello.go
# command-line-arguments
ar: `u' modifier ignored since `D' is the default (see `U')
[olej@dell tasks]$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=24bd1519714ce69e26d279a1bbf35ddcf2de8021, not stripped
[olej@dell tasks]$ ./hello
Hello, 世界

Но!!!
При этом нарушается работоспособность ранее установленного пакета GoLang:

Код: Выделить всё

[olej@dell tasks]$ go build -compiler gc hello.go
hello.go:10:8: cannot find package "fmt" in any of:
    /usr/src/fmt (from $GOROOT)
    /home/olej/2016_WORK/GoBook/src/fmt (from $GOPATH)
package runtime: cannot find package "runtime" in any of:
    /usr/src/runtime (from $GOROOT)
    /home/olej/2016_WORK/GoBook/src/runtime (from $GOPATH)

В нескольких предыдущих версиях Go и дистрибутивах Linux такого не наблюдалось.
Что это?

[Olej]

При этом нарушается работоспособность ранее установленного пакета GoLang:

Удалось выяснить, что это связано с переустановкой (неправильной) переменных окружения Go (не путать с переменными окружения Linux!).
При установке (работе) пакета golang:

Код: Выделить всё

[olej@dell gorun]$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/olej/2016_WORK/GoBook"
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT=""
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

Но при установке пакета gcc-go (и нарушенной работе компилятора gc)

Код: Выделить всё

[olej@dell tasks]$ go env
GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/olej/2016_WORK/GoBook"
GORACE=""
GOROOT="/usr"
GOTOOLDIR="/usr/libexec/gcc/x86_64-redhat-linux/5.3.1"
CC="/usr/bin/gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="/usr/bin/g++"
CGO_ENABLED="1"

После удаления gcc-go - работа gc восстанавливается:

Код: Выделить всё

sudo dnf remove gcc-go
...

Где определяются переменные окружения среды Go?
Как можно поменять значения отдельных переменных?

[serzh-z]

Где определяются переменные окружения среды Go?
Как можно поменять значения отдельных переменных?

Умолчальные значения захаркожены в компиляторе. Собственные значения можно передать через переменные среды.

Это не "нарушенная работа компилятора". Штатный компилятор go (тот, который раньше был gc) и компилятор Go для GCC используют разные подходы к компоновке приложения: go собирает статический ELF, gcc-go - линкует ELF с разделяемыми библиотеками. Соответственно, GOROOT для go и GOROOT gcc-go - это разные и несовместимые вещи.

Решением (если нужно быстро переключаться между компиляторами), наверное, будет создание копии всего GOROOT для golang и явное указание GOROOT при использовании `-compiler gc`.

Почему авторы не gcc-go не отладили переключение на альтернативный компилятор? Думаю, что потому же, почему и Google не интегрировала к себе поддержку GCC. =)

P.S.: в Arch Linux, кстати говоря, вообще запрещается ставить одновременно go и gcc-go. Надо полагать, что мейнтейнеры этих пакетов пошли таким путём далеко не просто так.

[Olej]

Это не "нарушенная работа компилятора". Штатный компилятор go (тот, который раньше был gc) и компилятор Go для GCC используют разные подходы к компоновке приложения: go собирает статический ELF, gcc-go - линкует ELF с разделяемыми библиотеками. Соответственно, GOROOT для go и GOROOT gcc-go - это разные и несовместимые вещи.

Это не так.
Так было в предыдущих версиях (до 1.4?).

Код: Выделить всё

[olej@dell ~]$ dnf info golang-shared
Последняя проверка окончания срока действия метаданных: 8 days, 17:14:54 назад, Sun May 22 23:18:30 2016.
Доступные пакеты
Имя         : golang-shared
Архитектура : x86_64
Эпоха       : 0
Версия      : 1.5.4
Релиз       : 1.fc23
Размер      : 12 M
Репозиторий : updates
Краткое опи : Golang shared object libraries
URL         : http://golang.org/
Лицензия    : BSD and Public Domain
Описание    : Golang shared object libraries.

[olej@dell ~]$ sudo dnf install golang-shared
...
Установлено:
  golang-shared.x86_64 1.5.4-1.fc23

Код: Выделить всё

[olej@dell tasks]$ go build -linkshared ./hello.go

[olej@dell tasks]$ go build -o hellos ./hello.go

[olej@dell tasks]$ ls -l hello*
-rwxr-xr-x. 1 olej olej   15816 май 31 16:38 hello
-rw-rw-r--. 1 olej olej     266 май 31 11:05 hello.go
-rwxr-xr-x. 1 olej olej 2367424 май 31 16:38 hellos

[olej@dell tasks]$ file hello*
hello:    ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ecbaadbe3483b60da122274f34abadf78d68b236, not stripped
hello.go: C source, UTF-8 Unicode text
hellos:   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

[olej@dell tasks]$ ./hello
Hello, 世界

[olej@dell tasks]$ ./hellos
Hello, 世界

[olej@dell tasks]$ ldd hello
    linux-vdso.so.1 (0x00007ffe5fbf4000)
    libstd.so => /usr/lib/golang/pkg/linux_amd64_dynlink/libstd.so (0x00007f8bfbd9b000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f8bfb9bc000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8bfb79f000)
    /lib64/ld-linux-x86-64.so.2 (0x000056212c4b6000)
[olej@dell tasks]$ ldd hellos
    не является динамическим исполняемым файлом

Вот 2 сборки, обе выполнениы компилятором gc (никакого другого там просто нет).

[Olej]

Как можно поменять значения отдельных переменных?

Умолчальные значения захаркожены в компиляторе. Собственные значения можно передать через переменные среды.

Как оказалось, да, установленные переменные окружения GO-среда не переисывает, она только устанавливает отсутствующие переменные.

Код: Выделить всё

[olej@dell api]$ go env GOROOT
/usr/lib/golang
[olej@dell api]$ export GOROOT=/usr
[olej@dell api]$ go env GOROOT
/usr
[olej@dell api]$ export GOROOT=/usr/lib/golang
[olej@dell api]$ go env GOROOT
/usr/lib/golang

[Olej]

Штатный компилятор go (тот, который раньше был gc) и компилятор Go для GCC используют разные подходы к компоновке приложения: go собирает статический ELF, gcc-go - линкует ELF с разделяемыми библиотеками. Соответственно, GOROOT для go и GOROOT gcc-go - это разные и несовместимые вещи.

До 1.4 (включительно) во всех предыдущих версиях это не создавало никаких проблем:

Код: Выделить всё

bash-4.2$ lsb_release -ircd
Distributor ID: Fedora
Description:    Fedora release 20 (Heisenbug)
Release:        20
Codename:       Heisenbug

Код: Выделить всё

bash-4.2$ go version
go version go1.4.2 linux/386

bash-4.2$ gccgo --version
gccgo (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
Copyright (C) 2013 Free Software Foundation, Inc.

Код: Выделить всё

bash-4.2$ go env
GOARCH="386"
GOBIN=""
GOCHAR="8"
GOEXE=""
GOHOSTARCH="386"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_386"
CC="gcc"
GOGCCFLAGS="-fPIC -m32 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

Это никак не препятствует выполнению gccgo:

Код: Выделить всё

bash-4.2$ go build -compiler gc -o tinyl tiny.go

bash-4.2$ go build -compiler gccgo -o tinyg tiny.go

bash-4.2$ ls -l tiny*
-rwxrwxr-x 1 Olej Olej   24317 июн  1 14:01 tinyg
-rw-rw-r-- 1 Olej Olej     111 июн  1 14:00 tiny.go
-rwxrwxr-x 1 Olej Olej 1569664 июн  1 14:01 tinyl

bash-4.2$ ./tinyg
минимальное приложение

bash-4.2$ ./tinyl
минимальное приложение

2 приложения, с разной компиляцией и сборкой, прекрасно собираются рядом.
Так же было во всех предыдущих версиях Go (и в самых разных дистрибутивах Linux).

[serzh-z]

Это не так.

Ок, golang-shared - это дополнительный пакет для golang 1.5 и отношения к gcc-go он не имеет. Из его не следует, что версия go из gcc-go обязан с ним работать.

[Olej]

Это не так.

Ок, golang-shared - это дополнительный пакет для golang 1.5 и отношения к gcc-go он не имеет. Из его не следует, что версия go из gcc-go обязан с ним работать.

Из него следует, что golang сейчас замечательно собирает ELF-приложение с подключением shared библиотек (не только static).

[Olej]

Как можно поменять значения отдельных переменных?

Умолчальные значения захаркожены в компиляторе. Собственные значения можно передать через переменные среды.

Как оказалось, да, установленные переменные окружения GO-среда не переисывает, она только устанавливает отсутствующие переменные.

А нифига

Код: Выделить всё

[olej@dell gdbinit.d]$ export GOROOT=/usr/lib/golang

[olej@dell tasks]$ export GOTOOLDIR=/usr/lib/golang/pkg/tool/linux_amd64

[olej@dell tasks]$ env | grep GO
GOTOOLDIR=/usr/lib/golang/pkg/tool/linux_amd64
GOROOT=/usr/lib/golang
GOPATH=/home/olej/2016_WORK/GoBook

[olej@dell tasks]$ go env
GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/olej/2016_WORK/GoBook"
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/libexec/gcc/x86_64-redhat-linux/5.3.1"
CC="/usr/bin/gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="/usr/bin/g++"
CGO_ENABLED="1"

[olej@dell tasks]$ env | grep GO
GOTOOLDIR=/usr/lib/golang/pkg/tool/linux_amd64
GOROOT=/usr/lib/golang
GOPATH=/home/olej/2016_WORK/GoBook

gccgo создаёт для себя свою копию окружения, в котором переписывает GOTOOLDIR как сам считает нужным.

Код: Выделить всё

[olej@dell tasks]$ go build -compiler gc hello.go
go tool: no such tool "6g"

[Olej]

Почему авторы не gcc-go не отладили переключение на альтернативный компилятор? Думаю, что потому же, почему и Google не интегрировала к себе поддержку GCC. =)

Это было бы довольно странно, если бы так:
- где-то проскакивала информация, что код Go в GCC - это не независимый, автономно разрабатываемый код, а тот же код из GoLang, разрабатываемый в плотном сотрудничестве...
- проект GoLang поддерживает и описывает в официальной документации опцию компилятора -compiler gccgo - использовать для компиляции компилятор GCC
- на сайте https://golang.org несколько страниц посвящены непосредственно gccgo
- ... да и проект golang.org - это не проект Google, а проект поддерживаемый Google, это не одно и то же ... с таким же успехом можно называть проектом Google и LLVM & Clang.

[Olej]

Штатный компилятор go (тот, который раньше был gc)

Почему "раньше был"?
А сейчас как?
Потому, что опция выбираемого компилятора (в help и документации) и сейчас выглядит так:

Код: Выделить всё

[olej@dell local]$ go version
go version go1.5.4 linux/amd64
[olej@dell tasks]$ go help build
...
   -compiler name
        name of compiler to use, as in runtime.Compiler (gccgo or gc).
...

Код: Выделить всё

[olej@dell tasks]$ go build -compiler gc hello.go
[olej@dell tasks]$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
[olej@dell tasks]$ go build -compiler gccgo hello.go
go build command-line-arguments: : fork/exec : no such file or directory

Как легко видеть, исполнимый файл создан именно компилятором gc.

[Olej]

До 1.4 (включительно) во всех предыдущих версиях это не создавало никаких проблем:

Код: Выделить всё

bash-4.2$ go version
go version go1.4.2 linux/386

bash-4.2$ gccgo --version
gccgo (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
Copyright (C) 2013 Free Software Foundation, Inc.

Код: Выделить всё

bash-4.2$ go env
GOARCH="386"
GOBIN=""
GOCHAR="8"
GOEXE=""
GOHOSTARCH="386"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_386"
CC="gcc"
GOGCCFLAGS="-fPIC -m32 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

Такое впечатление, что до Go 1.4 GCC вообще не выполнял компиляцию, а только вызывал как дочерние процессы утилиты GoLang:

Код: Выделить всё

bash-4.2$ ls /usr/lib/golang/pkg/tool/linux_386
5a  5c    5g  5l    6a  6c    6g  6l    8a  8c    8g  8l    addr2line  cgo    dist  fix  nm  objdump    pack  pprof  yacc

Сейчас (1.5) это совершенно автономные приложения:

Код: Выделить всё

[olej@dell gdbinit.d]$ go env
...
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/libexec/gcc/x86_64-redhat-linux/5.3.1"
...
[olej@dell tasks]$ ls /usr/libexec/gcc/x86_64-redhat-linux/5.3.1
cc1  cc1plus  cgo  collect2  go1  liblto_plugin.so  liblto_plugin.so.0  liblto_plugin.so.0.0.0  lto1  lto-wrapper
[olej@dell 5.3.1]$ ./cgo --help
usage: cgo -- [compiler options] file.go ...
  -cdefs=false: for bootstrap: write C definitions for C file to standard output
  -debug-define=false: print relevant #defines
  -debug-gcc=false: print gcc invocations
  -dynimport="": if non-empty, print dynamic import data for that file
  -dynlinker=false: record dynamic linker information in dynimport mode
  -dynout="": write -dynobj output to this file
  -gccgo=false: generate files for use with gccgo
  -gccgopkgpath="": -fgo-pkgpath option used with gccgo
  -gccgoprefix="": -fgo-prefix option used with gccgo
  -godefs=false: for bootstrap: write Go definitions for C file to standard output
  -import_runtime_cgo=true: import runtime/cgo in generated code
  -import_syscall=true: import syscall in generated code
  -objdir="": object directory

[Olej]

Всё что имеет отношение к этим эффектам может быть отражено, прямо или косвенно, в публикациях не раньше 19 August 2015 - даты официального объявления Go 1.5.

Как раз при переходе от 1.4 к 1.5 произошли радикальные изменения - Go 1.5 Release Notes, самое интересное:

The compiler and runtime are now implemented in Go and assembler, without C. The only C source left in the tree is related to testing or to cgo.

Now that the Go compiler and runtime are implemented in Go, a Go compiler must be available to compile the distribution from source. Thus, to build the Go core, a working Go distribution must already be in place. (Go programmers who do not work on the core are unaffected by this change.) Any Go 1.4 or later distribution (including gccgo) will serve.

The suites of programs that were the compilers (6g, 8g, etc.), the assemblers (6a, 8a, etc.), and the linkers (6l, 8l, etc.) have each been consolidated into a single tool that is configured by the environment variables GOOS and GOARCH. The old names are gone; the new tools are available through the go tool mechanism as go tool compile, go tool asm, and go tool link. Also, the file suffixes .6, .8, etc. for the intermediate object files are also gone; now they are just plain .o files.

As described above, the compiler in Go 1.5 is a single Go program, translated from the old C source, that replaces 6g, 8g, and so on. Its target is configured by the environment variables GOOS and GOARCH.

Go 1.5 Bootstrap Plan

Go 1.5 will use a toolchain written in Go (at least in part).
...
We have been planning for a year now to eliminate all C programs from the Go source tree. The C compilers (5c, 6c, 8c, 9c) have already been removed. The remaining C programs will be converted to Go: they are the Go compilers (golang.org/s/go13compiler), the assemblers, the linkers (golang.org/s/go13linker), and cmd/dist.

[serzh-z]

gccgo создаёт для себя свою копию окружения, в котором переписывает GOTOOLDIR как сам считает нужным.

GOTOOLDIR = GOROOT + pkg/tool/блаблабла. Если это не так, то, возможно, - это баг или особенностб версии в Fedora.

- ... да и проект golang.org - это не проект Google, а проект поддерживаемый Google, это не одно и то же ... с таким же успехом можно называть проектом Google и LLVM & Clang.

Это примерно так же, как лет 10 назад Mono "не был" проектом Microsoft. Хотя у Go, уверен, будущее более оптимистичное, просто в силу того, что у его истоков стояли куда более известные и уважаемые люди.

Почему "раньше был"?

gc - это, как я понимаю, компилятор Go, написанный на C. Теперь (1.6) Go полностью написан на самом себе. =)

Как легко видеть, исполнимый файл создан именно компилятором gc.

Стоит не забывать о том, что утилита go есть и в golang и в gcc-go. Это не одни и те же компиляторы. Просто ребята из GCC скопировали CLI-интерфейс golang. И, поскольку работа в gcc-go активно ведётся, не имеет смысла требовать от go из gcc-go аналогичного поведения. =) И, уж тем более, аналогичного поведение относительно переменных среды и форматов разделяемых библиотек.

[Olej]

Как легко видеть, исполнимый файл создан именно компилятором gc.

Стоит не забывать о том, что утилита go есть и в golang и в gcc-go. Это не одни и те же компиляторы. Просто ребята из GCC скопировали CLI-интерфейс golang. И, поскольку работа в gcc-go активно ведётся, не имеет смысла требовать от go из gcc-go аналогичного поведения. =) И, уж тем более, аналогичного поведение относительно переменных среды и форматов разделяемых библиотек.

Забывать не стоит ... но я вам показал сборку статическую и с разделяемыми библиотеками в системе, в которой установлен только один компилятор Go - GoLang.

Почему "раньше был"?

gc - это, как я понимаю, компилятор Go, написанный на C. Теперь (1.6) Go полностью написан на самом себе. =)

Не только 1.6, но и 1.5 (написан на Go).
Но опция компилятора как называлась gc, так и называется.
Предположу, что gc никак не имеет отношения к C, а производное от Go Compiler.

[Olej]

gccgo создаёт для себя свою копию окружения, в котором переписывает GOTOOLDIR как сам считает нужным.

GOTOOLDIR = GOROOT + pkg/tool/блаблабла. Если это не так, то, возможно, - это баг или особенностб версии в Fedora.

При установке golang : GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
Но после установки gcc-go : GOTOOLDIR="/usr/libexec/gcc/x86_64-redhat-linux/5.3.1"
И это не баг Fedora, не так всё просто ... как я уже показывал:

Код: Выделить всё

[olej@dell tasks]$ ls /usr/libexec/gcc/x86_64-redhat-linux/5.3.1
cc1  cc1plus  cgo  collect2  go1  liblto_plugin.so  liblto_plugin.so.0  liblto_plugin.so.0.0.0  lto1  lto-wrapper

Где, например (выборочно):

Код: Выделить всё

[olej@dell 5.3.1]$ ./cgo --help
usage: cgo -- [compiler options] file.go ...
  -cdefs=false: for bootstrap: write C definitions for C file to standard output
  -debug-define=false: print relevant #defines
  -debug-gcc=false: print gcc invocations
  -dynimport="": if non-empty, print dynamic import data for that file
  -dynlinker=false: record dynamic linker information in dynimport mode
  -dynout="": write -dynobj output to this file
  -gccgo=false: generate files for use with gccgo
  -gccgopkgpath="": -fgo-pkgpath option used with gccgo
  -gccgoprefix="": -fgo-prefix option used with gccgo
  -godefs=false: for bootstrap: write Go definitions for C file to standard output
  -import_runtime_cgo=true: import runtime/cgo in generated code
  -import_syscall=true: import syscall in generated code
  -objdir="": object directory

[Bizdelnick]

Это примерно так же, как лет 10 назад Mono "не был" проектом Microsoft.

Вообще-то с точностью до наоборот, ибо

известные и уважаемые люди

с самого начала все поголовно на зарплате у Google.

The Go programming language was conceived in late 2007 as an answer to some of the problems we were seeing developing software infrastructure at Google.

[Olej]

известные и уважаемые люди

с самого начала все поголовно на зарплате у Google.

Это так и это известно, но это и означает, что проект Go с самого начала финансируется Google ... точно так же, как и проекты LLVM & Clang (Google + Apple).
Но это вовсе не означает, что это проект Google.
Кто интересовался ранее, знают, что Go произрастает из проекта операционной системы Plan 9, Bell Labs. покойной, проектов Inferno & Limbo (пораньше самого Google ) ... и его родители оттуда.
И линия Go проекта GCC также развивается оттуда же, при активном взаимодействии с проектом GoLang.

Но всё это не так важно.

[Olej]

Стоит не забывать о том, что утилита go есть и в golang и в gcc-go. Это не одни и те же компиляторы. Просто ребята из GCC скопировали CLI-интерфейс golang. И, поскольку работа в gcc-go активно ведётся, не имеет смысла требовать от go из gcc-go аналогичного поведения. =) И, уж тем более, аналогичного поведение относительно переменных среды и форматов разделяемых библиотек.

Всё на месте, как оказалось : и аналогичное поведение, и переменные среды, и форматы разделяемых библиотек...
А нарушение одновременной установки и использования golang & gcc-go - это баг сборки ... скорее всего, майнтейнеров Fedora 23 ... или, не исключено, и make install проекта gcc-go.

Как оказалось:
- gcc-go при установке, если ссылка /etc/alternatives/go уже установлена в /usr/lib/golang/bin/go (т.е. golang уже установлен) не должен её переписывать, устанавливать в /usr/bin/go.gcc
- ... должен создавать ссылку только если её там нет
- ... а он это делает тупо в любом случае
- а golang при установке (после gcc-go) ссылку не переписывает
- ну и то же самое с ссылкой /etc/alternatives/gofmt

Теперь это легко поправить (пока не поправят в пакетной системе), делаем (я показываю это на 32-бит Fedora 23 - пути!):

Код: Выделить всё

[root@localhost alternatives]# cd /etc/alternatives
[root@localhost alternatives]# mv go go.gcc
[root@localhost alternatives]# mv gofmt gofmt.gcc
[root@localhost alternatives]# ln -s /usr/lib/golang/bin/go go
[root@localhost alternatives]# ln -s /usr/lib/golang/bin/gofmt gofmt

И теперь всё работает не мешая друг другу:

Код: Выделить всё

[olej@localhost GO]$ go build -compiler gc -o tiny.gc tiny.go
[olej@localhost GO]$ go build -compiler gccgo -o tiny.gcc tiny.go
# command-line-arguments
ar: `u' modifier ignored since `D' is the default (see `U')
[olej@localhost GO]$ ls -l tiny.*
-rwxr-xr-x. 1 olej olej 1905168 Jun  2 12:54 tiny.gc
-rwxr-xr-x. 1 olej olej   25528 Jun  2 12:55 tiny.gcc
-rw-r--r--. 1 olej olej     111 Jun  1 14:23 tiny.go

И можете наслаждаться:

Код: Выделить всё

[olej@localhost GO]$ file tiny.*
tiny.gc:  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
tiny.gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ceea47622da1118f6a98e3febfc687fc80a0d9b2, not stripped
tiny.go:  C source, UTF-8 Unicode text
[olej@localhost GO]$ ./tiny.gc
минимальное приложение
[olej@localhost GO]$ ./tiny.gcc
минимальное приложение

P.S. Как видите, всё скопировано с терминала, выполнением ... так что это не на словах.

[Bizdelnick]

- gcc-go при установке, если ссылка /etc/alternatives/go уже установлена в /usr/lib/golang/bin/go (т.е. golang уже установлен) не должен её переписывать, устанавливать в /usr/bin/go.gcc
- ... должен создавать ссылку только если её там нет
- ... а он это делает тупо в любом случае
- а golang при установке (после gcc-go) ссылку не переписывает

Это определяется приоритетом той или иной альтернативы. Видимо в Fedora 23 приоритет для gcc-go по какой-то причине решили сделать более высоким.
Upd. Так и есть, для go.gcc стоит приоритет 92, а для go — 90.

Теперь это легко поправить, делаем (я показываю это на 32-бит Fedora 23 - пути!)

Разве update-alternatives (или аналогичного скрипта) в Fedora нет?
Upd. Есть, так что лучше (удобнее и надёжнее) использовать его, а не делать линки вручную.

[Olej]

- gcc-go при установке, если ссылка /etc/alternatives/go уже установлена в /usr/lib/golang/bin/go (т.е. golang уже установлен) не должен её переписывать, устанавливать в /usr/bin/go.gcc
- ... должен создавать ссылку только если её там нет
- ... а он это делает тупо в любом случае
- а golang при установке (после gcc-go) ссылку не переписывает

Это определяется приоритетом той или иной альтернативы. Видимо в Fedora 23 приоритет для gcc-go по какой-то причине решили сделать более высоким.
Upd. Так и есть, для go.gcc стоит приоритет 92, а для go — 90.

Никакой подобной приоритетности ещё в Fedora 20 & Go 1.4 - не было.

Разве update-alternatives (или аналогичного скрипта) в Fedora нет?
Upd. Есть, так что лучше (удобнее и надёжнее) использовать его, а не делать линки вручную.

Есть, конечно:

Код: Выделить всё

[olej@localhost GO]$ update-alternatives --help
alternatives version 1.7 - Copyright (C) 2001 Red Hat, Inc.
This may be freely redistributed under the terms of the GNU Public License.

usage: alternatives --install <link> <name> <path> <priority>
                    [--initscript <service>]
                    [--family <family>]
                    [--slave <link> <name> <path>]*
       alternatives --remove <name> <path>
       alternatives --auto <name>
       alternatives --config <name>
       alternatives --display <name>
       alternatives --set <name> <path>
       alternatives --list

common options: --verbose --test --help --usage --version
                --altdir <directory> --admindir <directory>

Но мне нужно было увидеть что происходит и разобраться ... если никто во всём Интернет ничего внятного по поводу сказать не может.

[Bizdelnick]

Никакой подобной приоритетности ещё в Fedora 20 & Go 1.4 - не было.

А там для gcc вообще альтернативы не использовались.

[Olej]

Никакой подобной приоритетности ещё в Fedora 20 & Go 1.4 - не было.

А там для gcc вообще альтернативы не использовались.

Подсказали, что этот баг отмечен для Fedora 22 : Red Hat Bugzilla – Bug 1192716.

[Olej]

Разве update-alternatives (или аналогичного скрипта) в Fedora нет?
Upd. Есть, так что лучше (удобнее и надёжнее) использовать его, а не делать линки вручную.

Напишите готовые команды:

Код: Выделить всё

$ alternatives --install ...
$ alternatives --config ...

Чтобы ваши читатели не гадали над этими командами.

[Bizdelnick]

Мне лень, честно говоря, лезть в федоровские маны. В Debian это update-alternatives --config go

[Olej]

Мне лень, честно говоря, лезть в федоровские маны.

Ну лень - так лень
Мне тоже лень.
Себе то я напишу ... а остальные пусть дрочатся.

[Olej]

В Debian это update-alternatives --config go

До:

Код: Выделить всё

[olej@dell tasks]$ alternatives --list
...
go   auto   /usr/bin/go.gcc

[olej@dell tasks]$ alternatives --display go
go - статус "авто".
 ссылка сейчас указывает на /usr/bin/go.gcc
/usr/lib/golang/bin/go - priority 90
 slave gofmt: /usr/lib/golang/bin/gofmt
/usr/bin/go.gcc - priority 92
 slave gofmt: /usr/bin/gofmt.gcc
Текущая `лучшая' версия - /usr/bin/go.gcc.

Меняем:

Код: Выделить всё

[olej@dell tasks]$ sudo alternatives --config go
[sudo] пароль для olej:

Имеется 2 программ, которые предоставляют 'go'.

  Выбор    Команда
-----------------------------------------------
   1           /usr/lib/golang/bin/go
*+ 2           /usr/bin/go.gcc

Enter - сохранить текущий выбор[+], или укажите номер: 1

[olej@dell tasks]$ alternatives --display go
go - статус "вручную"
 ссылка сейчас указывает на /usr/lib/golang/bin/go
/usr/lib/golang/bin/go - priority 90
 slave gofmt: /usr/lib/golang/bin/gofmt
/usr/bin/go.gcc - priority 92
 slave gofmt: /usr/bin/gofmt.gcc
Текущая `лучшая' версия - /usr/bin/go.gcc.

После:

Код: Выделить всё

[olej@dell tasks]$ alternatives --display go
go - статус "вручную"
 ссылка сейчас указывает на /usr/lib/golang/bin/go
/usr/lib/golang/bin/go - priority 90
 slave gofmt: /usr/lib/golang/bin/gofmt
/usr/bin/go.gcc - priority 92
 slave gofmt: /usr/bin/gofmt.gcc
Текущая `лучшая' версия - /usr/bin/go.gcc.

4 разные сборки тестовой программы Go (всё выполено одновременно, без переустановок и настроек):

Код: Выделить всё

[olej@dell tasks]$ go build -compiler gc -o hellols hello.go
[olej@dell tasks]$ go build -compiler gc -linkshared -o hellold hello.go
[olej@dell tasks]$ go build -compiler gccgo -o hellog hello.go
[olej@dell tasks]$ gccgo -O3 hello.go -o helloi
[olej@dell tasks]$ ls -l hello*
-rwxr-xr-x. 1 olej olej   32400 июн  3 12:18 hellog
-rw-rw-r--. 1 olej olej     266 май 31 11:05 hello.go
-rwxrwxr-x. 1 olej olej   31984 июн  3 13:09 helloi
-rwxr-xr-x. 1 olej olej   15816 июн  3 12:18 hellold
-rwxr-xr-x. 1 olej olej 2367424 июн  3 12:17 hellols
[olej@dell tasks]$ ./helloi
Hello, 世界

[Olej]

Go Sub-repository Packages"
Здесь огромный репозитарий пакетов Go, ещё не входящих в стандартную библиотеку (в разработке), или для специальных целей (обработка изображений, сеть и т.д.).

These packages are part of the Go Project but outside the main Go tree. They are developed under looser compatibility requirements than the Go core.
Repositories

golang.org/x/blog — the content and server program for blog.golang.org.
golang.org/x/crypto — additional cryptography packages.
golang.org/x/exp — experimental code (handle with care).
golang.org/x/image — additional imaging packages.
golang.org/x/mobile — libraries and build tools for Go on Android.
golang.org/x/net — additional networking packages.
golang.org/x/sys — for low-level interactions with the operating system.
golang.org/x/talks — the content and server program for talks.golang.org.
golang.org/x/text — packages for working with text.
golang.org/x/tools — godoc, vet, cover, and other tools.

Здесь же далее следует кратное описание каждого пакета:

Packages
Path Synopsis
golang.org/x/arch/arm/armmap Armmap constructs the ARM opcode map from the instruction set CSV file.
...