Go compile returns duplicate symbols for architecture x86_64 error when I import 2 different packages which use C package via Cgo

Question

Here is my code:

package main

import (
    kusb "github.com/karalabe/usb"
    tusb "github.com/trezor/trezord-go/usb"
)

func main() {
    kusb.Enumerate(0, 0)
    tusb.InitHIDAPI(nil)
}

When I compile (I'm using go mod to manage the packages), it returns this error:

duplicate symbol _libusb_dev_mem_alloc in:
    /var/folders/fm/1rln65d94mn45s0h5l78tdyh0000gp/T/go-link-624554542/000002.o
    /var/folders/fm/1rln65d94mn45s0h5l78tdyh0000gp/T/go-link-624554542/000020.o
ld: 136 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Why?

Some investigation i had:

1. The both packages use the same hidapi and libusb C packages in order to interact with usb devices.
2. Those C packages are identical, hence it defines the same functions so i think it is directly related to the error.
3. in trezord-go/usb, they include .C file, not the header file.

It is very counterintuitive to me because in the perspective of package users, I shouldn't need to worry about how a C package is used in the internal of the package, only the exposed types, functions and its behaviors.

Can anyone really explain what is going on here and how can I import both of them? They do different functions, eventhough they use the same C package.

Rotman

what if rebuild trezord-go/usb with header include only? :) – Londalondon

Answer 1

From here: https://www.repustate.com/blog/go-duplicate-symbols-for-architecture-x86_64/

"What does this mean? Well, it means we're trying to link the same symbol name (in our case, a method) from two (or more) different source files. The fix was easy: rename one of the methods by updating the header file, the source file (.c or .cpp file) and lastly, updating your references to the symbol in your Go code, if it is directly referenced there."

Will it help ?

Forever

Answer 2

I was running into the same issue for hours and finally found the fix on a google groups channel

A package you import could be using cgo, you don't have to be using it directly ... You can try CGO_ENABLED=0 go build and if it works then it is cgo related.

This was the charm that i was looking for! Hope this works for you too.

Jeroldjeroma