gcc-go and go package conflict on Arch Linux, input and discussion

[Niklas Schnelle]

Hi Go Community,

as of the update to gcc 5.1 and therefor gcc-go 5.1 the Arch Linux package for standard go and gcc-go conflict because of the "go" and "gofmt" binaries and can't be installed together.
I have created the following bug report https://bugs.archlinux.org/task/45077 that discusses a few problems with the current conflict 

but am unsure about the correct solution so maybe we can discuss what the solution should be and then work with the distribution maintainers to implement it. 
Note that because of it's rolling release nature Arch is the first distribution to hit this problem but it will likely affect others in the future or maybe already has in development

versions.

[Ian Lance Taylor]

I really don't know what the right fix is.

It makes sense for gc and gccgo to provide both a go and gofmt
command. People who only install one or the other should get those
commands. It would be annoying to have to use different build
commands for the two toolchains.

I know that some distros have an /etc/alternatives directory for tools
that are provided by multiple packages. I'm sure it's somewhat
painful but perhaps that is the right approach here.

Ian

[andrewc...@gmail.com]

perhaps there should be something like gc-gotool and gccgo-gotool and a symlink. I think pacman has a way to do a choice when there is a conflict, and point the symlink to the right place.

[minux]

I don't think having multiple copies of gofmt is a big problem, because

they're mostly interchangeable. But the go tool issue is more interesting.

There is another related problem: cross compiling gccgo will compile a

go tool for the target, but not for the host. You can compile a gccgo

for the host, but the go tool only knows how to compile for the host,

and does not know anything about the cross toolchains you have.

I think one solution is to decouple the toolchain configuration from the

go tool (right now all the tool paths are hardcoded into the go tool source),

and this will also help with the go tool in gc (think about CC for multiple

platforms)

My proposal is that we agree upon some configuration format (JSON),

and make gccgo install new configuration files for newly built toolchain.

We can do the same for gc, and then we can unify those two go tools.

I know we generally frown upon configuration files, but I think this issue

is different. There is no way to automatically detect correct toolchain

settings, and we are now hiding the configuration problem by hardcoding

the setting into the binary.

If this new proposal is implemented, then future distributions only need

to keep the most recent version of the go tool (generally the gc version).

Of course, we still need to decide how could the go tool find the toolchain

configuration files: for gc, it's easy, as go tool from gc doesn't aim to

support multiple gc versions, so it just need to look in $GOROOT/pkg,

but the problem is harder for gccgo.

[Forud A]

gofmt and other go tools are not depend on go. they can be in seperate package (not depend on go,gccgo) and both gcc-go and go can depend on that one.

[andrewc...@gmail.com]

There is another related problem: cross compiling gccgo will compile a

go tool for the target, but not for the host. You can compile a gccgo

for the host, but the go tool only knows how to compile for the host,

and does not know anything about the cross toolchains you have.

Not building a host version of the go tool is a bug, at least it looks like it from the Makefile.am file. Do distributions usually ship cross compilers in the package repos? It seems like it depends too much on which kernel/libc you are using to do reliably.

[minux]

On Tue, May 26, 2015 at 12:50 AM, Forud A <fz...@rubi.gd> wrote:

gofmt and other go tools are not depend on go. they can be in seperate package (not depend on go,gccgo) and both gcc-go and go can depend on that one. 

The one that is bundled with gccgo, by default, is dynamically linked, so they

do depend on gccgo for libgo.so.

And as I mentioned earlier, having a single copy of go tool won't work correctly

for various cases.

For example, if the gccgo binary is not in the PATH (or have suffixes attached).

The default compiler will also be wrong (if the user only has gccgo installed, then

the gccgo go tool will use gccgo by default; however the gc version of the go tool

will use gc by default)

[minux]

I‘m not that sure it's a bug.

If we fix the "bug", then to compile a cross gccgo, the host version also needs

to be compiled, but so far the gcc build system doesn't do that normally (host

tools are compiled with host toolchain, not by a newly built toolchain) and the

build time will also double (or more, if we use three stage bootstrap build for

the host assuming build == host). Not to mention that it will also pose problem

for canadian cross (in that case, by the same reasoning, building gccgo should

produce a go tool for the build, for the host and also for the target; but obviously

we couldn't require a copy of gccgo is available for build or host, so we will

need to build gcc and its backend three times).

I think a similar problem also arises in gcj. If you cross compile gcj, then gjar,

gjavah and related tools will be for the target, not for the host.

[andrewc...@gmail.com]

I‘m not that sure it's a bug.

Off topic, but this is definitely a problem for a few reasons.

1. It installs a target binary into the host output directory, having target binaries in a host directory is obviously an error.
2. --host is where the compiler intends to run, having a go tool for --target is useless because it has no compiler there.
3. It is common sense if you are trying to build a cross compiler, you want a go tool which will actually allow you to cross compile.

Back on topic:

perhaps renaming the gccgo go tool is the best option tbh (it has come second afterall) . I really think It makes sense to have a go tool which defaults to using gccgo without any magic flags though.

I think gccgo is much less popular than it deserves because people don't understand how to use it properly. People would understand "gccgo build" / "gccgo install" etc. It is a shame the compiler proper is already named this (gccgc would have been less confusing).

[andrewc...@gmail.com]

If we fix the "bug", then to compile a cross gccgo, the host version also needs

to be compiled.

Not true, autotools should check for a working go tool or gccgo and error if one isn't specified.

[minux]

On Tue, May 26, 2015 at 1:27 AM, <andrewc...@gmail.com> wrote:

I‘m not that sure it's a bug.

Off topic, but this is definitely a problem for a few reasons.

I’m referring the fact it installs a target go binary.

[minux]

are you suggesting that to cross compile gccgo, one must first have gccgo for the

host version? Just to build the host go tool? Why? I don't like this solution.

Another related problem is having a go tool that can only cross compile for a specific

target?

What if I want to have to build Go for multiple architectures? Then I will have to have

one go tool for each gccgo target? The gc go tool doesn't have this restriction, a

single Go tool can build for all support platforms.

[andrewc...@gmail.com]

On Tuesday, May 26, 2015 at 6:06:31 PM UTC+12, minux wrote:

On Tue, May 26, 2015 at 1:30 AM, <andrewc...@gmail.com> wrote:

If we fix the "bug", then to compile a cross gccgo, the host version also needs

to be compiled.

Not true, autotools should check for a working go tool or gccgo and error if one isn't specified.

are you suggesting that to cross compile gccgo, one must first have gccgo for the

host version? Just to build the host go tool? Why? I don't like this solution.

You already have a tarball with the source code, so you can build and install a host gccgo first no problem.
The alternative is doing two gcc builds which is less flexible, horrible, and would require reworking all of gcc's build scripts.

Another related problem is having a go tool that can only cross compile for a specific

target?

What if I want to have to build Go for multiple architectures? Then I will have to have

one go tool for each gccgo target? The gc go tool doesn't have this restriction, a

single Go tool can build for all support platforms.

This is a real issue that affects packaging and go in general. I think one go tool per toolchain would actually be fine. I think this is especially true because the gccgo version of the go tool is probably going to diverge from the gc tool over time to the point where they will become incompatible. I think the gccgo version is already behind the gc version, and they can't sync up unless the release schedule of gc and gcc synchronize.

[minux]

On Tue, May 26, 2015 at 2:20 AM, <andrewc...@gmail.com> wrote:

On Tuesday, May 26, 2015 at 6:06:31 PM UTC+12, minux wrote:

On Tue, May 26, 2015 at 1:30 AM, <andrewc...@gmail.com> wrote:

If we fix the "bug", then to compile a cross gccgo, the host version also needs

to be compiled.

Not true, autotools should check for a working go tool or gccgo and error if one isn't specified.

are you suggesting that to cross compile gccgo, one must first have gccgo for the

host version? Just to build the host go tool? Why? I don't like this solution.

You already have a tarball with the source code, so you can build and install a host gccgo first no problem.
The alternative is doing two gcc builds which is less flexible, horrible, and would require reworking all of gcc's build scripts.

No, that's not the only alternative. I've proposed another alternative solution: decoupled

the toolchain configuration from the go tool binary. Install the toolchain configuration for

the cross compile toolchain, then the user can use any go tool on the host.

Another related problem is having a go tool that can only cross compile for a specific

target?

What if I want to have to build Go for multiple architectures? Then I will have to have

one go tool for each gccgo target? The gc go tool doesn't have this restriction, a

single Go tool can build for all support platforms.

This is a real issue that affects packaging and go in general. I think one go tool per toolchain would actually be fine. I think this is especially true because the gccgo version of the go tool is probably going to diverge from the gc tool over time to the point where they will become incompatible. I think the gccgo version is already behind the gc version, and they can't sync up unless the release schedule of gc and gcc synchronize.

The go tool in the gc suite also support -compiler gccgo, so I don't think the two go tool

will diverge over time (not to mention that the libgo copy of go tool source code is synced

from the master repository).

[andrewc...@gmail.com]

On Tuesday, May 26, 2015 at 6:32:00 PM UTC+12, minux wrote:

On Tue, May 26, 2015 at 2:20 AM, <andrewc...@gmail.com> wrote:

On Tuesday, May 26, 2015 at 6:06:31 PM UTC+12, minux wrote:

On Tue, May 26, 2015 at 1:30 AM, <andrewc...@gmail.com> wrote:

If we fix the "bug", then to compile a cross gccgo, the host version also needs

to be compiled.

Not true, autotools should check for a working go tool or gccgo and error if one isn't specified.

are you suggesting that to cross compile gccgo, one must first have gccgo for the

host version? Just to build the host go tool? Why? I don't like this solution.

You already have a tarball with the source code, so you can build and install a host gccgo first no problem.
The alternative is doing two gcc builds which is less flexible, horrible, and would require reworking all of gcc's build scripts.

No, that's not the only alternative. I've proposed another alternative solution: decoupled

the toolchain configuration from the go tool binary. Install the toolchain configuration for

the cross compile toolchain, then the user can use any go tool on the host.

We are mashing two different issues into one thread. Are you on #go-nuts ? One issue is how to get a working go tool while cross compiling, the other issue is whether users should expect to have multiple go tools installed no matter how many different cross compilers and different toolchains are installed.
 

[andrewc...@gmail.com]

No, that's not the only alternative. I've proposed another alternative solution: decoupled

the toolchain configuration from the go tool binary. Install the toolchain configuration for

the cross compile toolchain, then the user can use any go tool on the host.

This issue needs to be fixed for 5.1 which is being packaged and has already been released. Something like that could be done in the future, but for now It won't help. A simple and general solution is to advise distributions which are packaging gcc 5.1 to rename gofmt cgo and go to have a gccgo- prefix and provide a patch for issues caused by those name changes.

[Niklas Schnelle]

Just wanted to note that llgo uses the prefix solution and provides a go tool (probably less close to the gc go tool than the one in gccgo) as llgo-go