Spurious 'Rust FFI library not found' error in init() when using pre-built binaries

[bkvarda]

Problem

When using the zerobus-sdk-go library with pre-built Rust binaries (as documented in the README), the init() function in build.go prints a large error message even though the library is correctly statically linked and functional.

The error appears on every program start:

═══════════════════════════════════════════
ERROR: Rust FFI library not found
...
═══════════════════════════════════════════

Root Cause

The init() function in build.go uses runtime.Caller(0) to get the source file path, then checks if the .a library file exists at that path:

func init() {
    _, filename, _, ok := runtime.Caller(0)
    // ...
    sdkDir := filepath.Dir(filename)
    libPath := filepath.Join(sdkDir, "lib", fmt.Sprintf("%s_%s", runtime.GOOS, runtime.GOARCH), "libzerobus_ffi.a")
    if _, err := os.Stat(libPath); os.IsNotExist(err) {
        // Prints error message
    }
}

The problem is that runtime.Caller(0) returns the source file path that was embedded at compile time (e.g., the CI build machine's module cache path). When the compiled binary runs on a different machine, that path doesn't exist, so the check fails.

However, the Rust library is correctly statically linked into the binary via CGO - the functionality works fine. This is just a spurious runtime check that doesn't reflect reality.

Impact

• Every program using zerobus-sdk-go with pre-built binaries shows this error on startup
• Users may think the library isn't working when it actually is
• The error message is alarming and confusing

Proposed Fix

The simplest fix is to remove or disable this runtime check, since:

1. The library is statically linked at build time - if linking failed, the build would fail
2. The check doesn't validate that the library is actually linked, only that a file exists at a path
3. The path embedded by runtime.Caller(0) is not meaningful at runtime on a different machine

Options:

1. Remove the check entirely - If the build succeeds, the library is linked
2. Make it a build-time check only - Use a build constraint or move to a tool that runs during go generate
3. Add an environment variable to disable the check - e.g., ZEROBUS_SKIP_LIB_CHECK=1

Workaround

Currently we work around this by capturing stderr during init and filtering out the error message, but this is fragile and shouldn't be necessary.

Environment

• zerobus-sdk-go version: v0.2.1
• Go version: 1.23
• Platforms affected: darwin/arm64, darwin/amd64, linux/amd64 (all platforms using pre-built binaries distributed via CI)

[elenagaljak-db]

Hey @bkvarda, thanks for taking the time to file this and write a detailed issue. I agree that the error is misleading given that the library is already statically linked and working, and it shouldn't be happening.
We will look into solving this issue (most likely with option 1 that you proposed).
Thanks!