mirror of
https://github.com/getAlby/hub.git
synced 2026-08-13 12:33:39 +02:00
* 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> |
||
|---|---|---|
| .. | ||
| bark | ||
| cashu | ||
| cln | ||
| ldk | ||
| lnd | ||
| phoenixd | ||
| models.go | ||