Installing the Ark Bitcoin SDK on OpenBSD

The Ark protocol (Second) ships a Go SDK that wraps a Rust Bitcoin library via UniFFI and CGo. The getting-started guide takes about five minutes on Linux or macOS. On OpenBSD it took considerably longer — not because anything was fundamentally broken, but because the SDK silently assumes a GCC/glibc/libunwind world that doesn't exist on OpenBSD's clang stack.

What follows is a complete incident log: every error encountered, the root cause of each, and the exact fix applied.

The SDK's cgo.go file contains a build matrix that maps OS/arch combinations to precompiled libbark_ffi_go.a static libraries bundled into the module. The matrix covers Linux (x86_64, arm64, arm, i686), macOS (x86_64, arm64), Windows (x86_64), Android, and iOS.

OpenBSD is not in the matrix. Running go build immediately exits with a linker error because there is no .a to link against.

The only path forward was compiling libbark_ffi_go.a from Rust source. This required installing the full toolchain first:

# Prerequisites
pkg_add git protobuf
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env

# Clone and compile
git clone https://gitlab.com/ark-bitcoin/bark-ffi-bindings
cd bark-ffi-bindings
cargo build --release --lib
    

The Rust build completed in approximately 7 minutes and 42 seconds, producing a 24.2 MB libbark_ffi_go.a at target/release/.

With the static lib compiled and CGO_LDFLAGS pointing at it, go build failed with a wall of undefined symbol errors:

_Unwind_Resume
_Unwind_RaiseException
_Unwind_GetIP
_Unwind_GetRegionStart
_Unwind_GetLanguageSpecificData
... (dozens more)
    

These are C++ exception unwinding symbols. The Rust library uses panic = "unwind" internally and pulls in these symbols through its C++ runtime dependency.

On Linux these are typically satisfied by libgcc_s or libunwind. On macOS, libc++abi. On OpenBSD, neither -lgcc nor -lunwind exist — the system uses a pure clang/libc++ toolchain with no GCC artifacts.

OpenBSD ships libc++abi.a in /usr/lib/, which contains all the _Unwind_* symbols. Adding -lc++abi to CGO_LDFLAGS resolved the entire block:

CGO_LDFLAGS="-L/path/to/release -lbark_ffi_go -lc++abi"
    

After resolving the unwind symbols, the build failed again on missing floating-point math functions:

undefined reference to `pow'
undefined reference to `log'
    

The Rust library embeds sqlite3, which uses floating-point math internally. On Linux, libm is often linked implicitly. On OpenBSD with CGo, it is not.

Add -lm to CGO_LDFLAGS:

CGO_LDFLAGS="-L/path/to/release -lbark_ffi_go -lc++abi -lm"
    

Even with the static .a correctly specified in CGO_LDFLAGS, the linker was silently preferring a .so shared library present in the same Cargo output directory. This caused the final binary to dynamically link at runtime — which fails on any machine where the .so isn't on the library path.

Delete the .so to force static-only linking:

rm target/release/libbark_ffi_go.so
    

With the .so absent, the linker uses the .a unconditionally and the binary is fully self-contained.

The SDK uses a C header (bark.h) generated by UniFFI. Without an explicit path, the build fails with a standard "no such file or directory" error during compilation.

Set CGO_CFLAGS to point at the header directory inside the Go module cache:

CGO_CFLAGS="-I$GOPATH/pkg/mod/gitlab.com/ark-bitcoin/bark-ffi-bindings/golang@v0.2.0-beta.1/bark"
    

Phase 2 added onchain Bitcoin wallet functionality. Initial code guessed at OnchainBalance struct fields based on the Ark wallet's equivalent type, using bal.Confirmed and bal.TrustedPending. Build failed:

bal.Confirmed undefined (type OnchainBalance has no field or method Confirmed)
bal.TrustedPending undefined (type OnchainBalance has no field or method TrustedPending)
    

Reading the actual Go SDK source (bark.go) revealed the correct field names:

// OnchainBalance — actual fields from source
type OnchainBalance struct {
    ConfirmedSats  uint64
    PendingSats    uint64
    TotalSats      uint64
}
    

Because the build was iterative, wallet data directories from earlier runs were left on disk. On the next successful build, the SDK refused to start — it would not overwrite an existing wallet config at the same path.

Use fresh data directory paths for each new wallet instance during iteration:

arkDataDir     := "/home/bark-wallet/.bark/my_wallet3"
onchainDataDir := "/home/bark-wallet/.bark/my_wallet3_onchain"