Why do I get "duplicate symbol reference" when including two cgo based libraries?

Question

I'm trying to build (go build) the following:

package main

import (
    "fmt"
    _ "github.com/d2g/unqlitego"
    _ "github.com/mattn/go-sqlite3"
)

func main() {
    fmt.Println("Erm Compile?")
}

and I get an error:

duplicate symbol reference: __moddi3 in both github.com/d2g/unqlitego( .text) and github.com/mattn/go-sqlite3(.text)

I'm running go version go1.3.1 windows/386.

Am I doing something wrong? How would you resolve this sort of issue?

Is this OS/Go Version/Architecture specific bug? (I'd appreciate "it works for me" with the output from your go version)

I've put this all in a repo so you should be able to just go get github.com/d2g/issue-duplicate_symbol.

As per comments looks like a Windows 386 issue logged on: https://code.google.com/p/go/issues/detail?id=8702

Hooch

Darn: go version go1.3.1 windows/amd64, but I don't have gcc on my %PATH%. Is it possible you have sqlite3.dll somewhere else on your disk, that might interfere in this compilation? – Soane

If I comment out either library it compiles. Which suggests it's to do with how they interact at compile time? – Hooch

Weird, because Go usually does magic to keep C symbol names from conflicting as long as they're wrapped by separate packages. – Staff

Works for me go1.3 Windows amd64 – Staff

Just updated to 1.3.1, still works on Windows amd64 – Staff

I'm getting the same issue using 1.2 Windows/386. – Modernistic

Looks like it might be a 386 issue then? – Staff

Confirmed. Changing GOARCH to 386 causes the conflict. – Staff

Windows specific issue: see code.google.com/p/go/issues/detail?id=8756, won't be fixed until version 1.5 – Eileen

go version go1.3.2 linux/amd64 it works for me. – Wiper

Answer 1

@AndrewN notes that this is a Windows specific issue: see golang.org/issue/8756 or original issue at code.google.com/p/go/issues/detail?id=8756, won't be fixed until version 1.5.

(Documenting so this does not look like unanswered question).

Possibly