cmd/go: linking libgcc into every cgo object can cause multiple definition errors

[ianlancetaylor]

issue/a/a.go:

package a

/*
static long long mod(long long a, long long b) { return a % b; }
*/
import "C"

func F(a, b int64) int64 {
    return int64(C.mod(C.longlong(a), C.longlong(b)))
}

issue/b/b.go exactly the same except "package b" instead of "package a".

issue/main.go:

package main

import (
    "fmt"

    "issue/a"
    "issue/b"
)

func main() {
    fmt.Println(a.F(1, 1), b.F(1, 1))
}

GOARCH=386 go build issue

# issue
/var/tmp/go-link-0Vel41/000001.o: In function `__moddi3':
(.text+0x70): multiple definition of `__moddi3'
/var/tmp/go-link-0Vel41/000000.o:(.text+0x70): first defined here
collect2: error: ld returned 1 exit status
/home/iant/go/pkg/tool/linux_amd64/8l: running gcc failed: unsuccessful exit status 0x100

The problem is that for GOARCH=386 both object files require __moddi3. The go command links both cgo objects against libgcc, because of issue #3261. So both object files define __moddi3, and the linker complains.

On systems that support external linking, which I think is everything but Windows, it should no longer be necessary to link libgcc into each cgo object file. Unless, of course, the standard packages that use cgo (net, crypto/x509) use a libgcc function.

[mdempsky]

iant: Did you have a solution in mind for this? I'm thinking something along the lines of:

1. Have cmd/go/build.go stop passing -lgcc, -lmingw32, etc. to "gcc -Wl,-r" when creating each cgo-using package's _all.o file.
2. In external linking mode, simply add back -lmingw32, etc. and it should resolve the missing symbols appropriately. (I assume -lgcc isn't needed since gcc should add it automatically?)
3. In internal linking mode, add an extra "gcc -Wl,-r" phase to collect all the per-package _all.o files into a single "_allall.o" file, and pass -lgcc, -lmingw32, etc. at that time. Then perform internal linking as normal using the one "_allall.o" file instead of every individual _all.o file.

I suspect part 3 could be constrained to only trigger in cases where we'd switch to external linking if it was supported (i.e., "runtime/cgo" imported and a non-internal host object file is present). However, I'm not sure I understand the purpose served by internal linking, so I'm unclear exactly when we'd want/need to omit those extra steps.

[minux]

The problem of your _allall.o approach is that internal linking is no longer
possible without gcc installed (think windows, where mingw is not normally
installed.)

The reason for having internal linking is that people just using standard
cgo packages (os/user, crypto/x509, net, etc.) will not need to have gcc
installed. If we always require gcc, then it's much better to always use
external linking mode for all cgo programs.

[mdempsky]

Ohh, I think I understand now: it's to support the use case where the standard library is pre-compiled on a system where GCC is present, then distributed to systems where it's not? If so, that makes sense. (I was confused how os/user, net, etc. could be compiled in the first place without GCC present.)

[minux]

Yes. We're talking about users of our binary distributions.
The internal linking mode is mostly for them.

[ianlancetaylor]

I agree with your items 1 and 2. Note that even -lmingw32 is added automatically. I doubt the go tool will need to add anything special.

Unfortunately as minux notes your item 3 is problematic. For internal linking it would be best if we didn't have to assume that libgcc.a was available at link time. But we also don't want to link it into the .o we build for the package that uses cgo. Unfortunately at the time we build that package we don't know whether we will be doing internal linking or not. We probably don't want to copy libgcc.a around, and we probably don't want to build every cgo package twice. I don't have a simple solution for this.

[minux]

Ian, is there some kind of linker magic that could split the object files
extracted from libgcc.a into a different output object file?

i.e. when linking _all.o, we link libgcc.a as usual, but put all needed
objects from libgcc.a into a separate _gcc.o, not to _all.o.

And we can include _gcc.o as needed when do the final linking, depending
on -linkmode.

The benefit is that, we do this for all cgo packages, so if the user wants,
they can still use internal linking for compatible cgo packages (that don't
use any feature not understand by our 6l.)

[mdempsky]

Wouldn't that just shift the problem of symbol collisions from _all.o to _gcc.o?

[minux]

_gcc.o is only used by our linker, and we can teach the linker to
ignore duplicates. (the go tool ignores files with underscore
prefixes, so any special handling of _gcc.o won't affect users'
code)

External linking will proceed as you've proposed, without using
_gcc.o.

[minux]

Another possibility is that we make the linker label symbols
from libgcc.a as dupok (common symbols?) when linking
_all.o.

[ianlancetaylor]

I'm not aware of any linker magic that will put only needed objects into a separate output file. Of course we could do this ourselves.

It is technically possible to mark the symbols from libgcc.a dupok (which in ELF and PE is called comdat--common symbols are also dupok but they are different), but again we would have to do it ourselves. It's non-trivial for ELF.