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) <noreply@anthropic.com>

* 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) <noreply@anthropic.com>

* 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) <noreply@anthropic.com>

* 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) <noreply@anthropic.com>

* 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) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.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

lnclient/bark/bark.go

@@ -1,3 +1,5 @@
+//go:build (darwin && (amd64 || arm64)) || (linux && (amd64 || arm64)) || (windows && amd64)
+
 package bark
 
 import (

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)
+}