Multiple Definition Errors When Linking Both btcd and lnd Static Libraries

[erickcestari]

When attempting to link both btcd and lnd modules (built as static libraries) into the same executable, the following linking errors occur:

/usr/bin/ld: modules/lnd/module.a(go.o): in function `_cgo_topofstack':
(.text+0x75ee0): multiple definition of `_cgo_topofstack'; modules/btcd/module.a(go.o):(.text+0x72160): first defined here
/usr/bin/ld: modules/lnd/module.a(go.o): in function `_cgo_panic':
/usr/lib/go/src/runtime/cgo/callbacks.go:46: multiple definition of `_cgo_panic'; modules/btcd/module.a(go.o):/usr/lib/go/src/runtime/cgo/callbacks.go:46: first defined here
/usr/bin/ld: modules/lnd/module.a(go.o): in function `crosscall2':
/usr/lib/go/src/runtime/cgo/asm_amd64.s:26: multiple definition of `crosscall2'; modules/btcd/module.a(go.o):/usr/lib/go/src/runtime/cgo/asm_amd64.s:26: first defined here

Similar to #90

[luisfg30]

It seems that when building multiple modules we start to have a problem of shared dependencies between them. For instance the rustbitcoin and rustminiscript had a name conflict on rustsecp256k1. Now we got a problem with go modules. Maybe a solution would be to create shared objects of the common dependencies? Them adjust that in the linking stage?

[apoelstra]

I think in general you might have to look at what cargo does -- building every single dependency separately as a rlib (or something) and then linking them all at once.z

[erickcestari]

We could consider accepting multiple definitions in the bitcoinfuzz Makefile. However, I'm uncertain about the potential consequences of implementing this approach.

ifeq ($(UNAME_S), Darwin)
    LDFLAGS = -framework CoreFoundation -Wl,-ld_classic -Wl,-allow_multiple_definition
else
    LDFLAGS = -Wl,-z,muldefs
endif