From df67a2c24efabf3e658ce9df5f41a9ac8d5852a3 Mon Sep 17 00:00:00 2001 From: Roland <33993199+rolznz@users.noreply.github.com> Date: Thu, 4 Jun 2026 17:20:04 +0700 Subject: [PATCH] fix: link Windows CNG libs for bark FFI (#2397) * fix: link Windows CNG libs for bark FFI The bark FFI static library is built for the GNU/mingw target and embeds Rust's getrandom/ring code, which references Windows CNG symbols such as BCryptGenRandom. The upstream bark bindings only link -lbark_ffi_go, so the mingw linker fails with "undefined reference to BCryptGenRandom". cgo merges LDFLAGS across packages, so supply the missing Windows system libraries from our own bark package without modifying the vendored module. Co-Authored-By: Claude Opus 4.8 (1M context) * fix: move cgo directive out of Go doc comment for bark windows The descriptive comment block was contiguous with the import "C" line, so the entire block became the cgo C preamble and the C compiler tried to parse the prose (unknown type name 'The', stray quotes/backticks). Separate the Go documentation from the cgo preamble with a blank line and keep only the #cgo directive in a /* */ block immediately preceding import "C". Co-Authored-By: Claude Opus 4.8 (1M context) * fix: link Windows CNG libs for bark via extldflags cgo #cgo LDFLAGS directives from our package are ordered before the bark module on the link line, so the single-pass mingw linker discards -lbcrypt before it sees the undefined BCryptGenRandom reference from libbark_ffi_go.a. Append the Windows system libraries via -extldflags instead, which places them after -lbark_ffi_go so the linker can resolve the symbols. Co-Authored-By: Claude Opus 4.8 (1M context) * fix: link bark Windows CNG libs via CGO_LDFLAGS start-group wails drops -ldflags=-extldflags, so the system libraries never reached the external linker. Set them through CGO_LDFLAGS instead (read directly by cgo) and wrap them with bark in a --start-group, so the linker re-scans the group and resolves BCryptGenRandom regardless of library order. Co-Authored-By: Claude Opus 4.8 (1M context) * fix: gate bark backend to platforms with prebuilt FFI libs The bark FFI bindings ship no native library for 32-bit ARM Linux, so the armv6 build failed to link bark's own FFI symbols. Constrain the real bark implementation to bark's supported platforms (darwin/linux amd64+arm64, windows amd64) and add a stub for everything else that returns an "unsupported" error if the bark backend is selected at runtime. Co-Authored-By: Claude Opus 4.8 (1M context) --------- Co-authored-by: Claude Opus 4.8 (1M context) --- .github/workflows/wails.yml | 12 +++++++++++- lnclient/bark/bark.go | 2 ++ lnclient/bark/bark_unsupported.go | 29 +++++++++++++++++++++++++++++ 3 files changed, 42 insertions(+), 1 deletion(-) create mode 100644 lnclient/bark/bark_unsupported.go diff --git a/.github/workflows/wails.yml b/.github/workflows/wails.yml index 71079d7c..d81f7511 100644 --- a/.github/workflows/wails.yml +++ b/.github/workflows/wails.yml @@ -123,9 +123,19 @@ jobs: run: wails build --platform linux/amd64 -webview2 embed -o "${{ env.EXEC_NAME }}" -tags "wails,webkit2_41" -ldflags "-X 'github.com/getAlby/hub/version.Tag=${{ env.TAG }}'" shell: bash + # The bark FFI static library is built for the GNU/mingw target and embeds + # Rust's getrandom/ring code, which references Windows CNG symbols such as + # BCryptGenRandom. The upstream bark bindings only link -lbark_ffi_go, so + # we link the missing Windows system libraries via CGO_LDFLAGS (cgo reads + # this directly; -ldflags/-extldflags get dropped by wails). They are + # wrapped together with bark in a --start-group so the linker re-scans the + # group and resolves the symbols regardless of library order on the line. - name: Build Windows App if: runner.os == 'Windows' - run: wails build --platform windows/amd64 -webview2 embed -o "${{ env.EXEC_NAME }}.exe" -tags "wails" -ldflags "-X 'github.com/getAlby/hub/version.Tag=${{ env.TAG }}'" + run: | + BARK_LIB="$(go list -m -f '{{.Dir}}' gitlab.com/ark-bitcoin/bark-ffi-bindings/golang)/lib/windows_amd64" + export CGO_LDFLAGS="-Wl,--start-group -L${BARK_LIB} -lbark_ffi_go -lbcrypt -lntdll -luserenv -lws2_32 -lcrypt32 -lncrypt -lsecur32 -ladvapi32 -Wl,--end-group" + wails build --platform windows/amd64 -webview2 embed -o "${{ env.EXEC_NAME }}.exe" -tags "wails" -ldflags "-X 'github.com/getAlby/hub/version.Tag=${{ env.TAG }}'" shell: bash - name: Import Code-Signing Certificates for macOS diff --git a/lnclient/bark/bark.go b/lnclient/bark/bark.go index 57f04275..45ce3359 100644 --- a/lnclient/bark/bark.go +++ b/lnclient/bark/bark.go @@ -1,3 +1,5 @@ +//go:build (darwin && (amd64 || arm64)) || (linux && (amd64 || arm64)) || (windows && amd64) + package bark import ( diff --git a/lnclient/bark/bark_unsupported.go b/lnclient/bark/bark_unsupported.go new file mode 100644 index 00000000..81842341 --- /dev/null +++ b/lnclient/bark/bark_unsupported.go @@ -0,0 +1,29 @@ +//go:build !((darwin && (amd64 || arm64)) || (linux && (amd64 || arm64)) || (windows && amd64)) + +package bark + +import ( + "context" + "fmt" + "runtime" + + "github.com/getAlby/hub/events" + "github.com/getAlby/hub/lnclient" +) + +// The bark FFI bindings only ship prebuilt native libraries for a subset of +// platforms (notably not 32-bit ARM Linux). On every other platform this stub +// is compiled instead of bark.go so the rest of Alby Hub still builds, and the +// bark backend simply reports that it is unavailable if selected at runtime. + +// Config mirrors the real bark.Config so callers compile on all platforms. +type Config struct { + Network string + ServerAddress string + EsploraAddress string + ServerAccessToken string +} + +func NewBarkService(ctx context.Context, eventPublisher events.EventPublisher, workDir, mnemonic string, config Config) (lnclient.LNClient, error) { + return nil, fmt.Errorf("the bark backend is not supported on %s/%s", runtime.GOOS, runtime.GOARCH) +}