What happens?

Hello,

We maintain a Go project on Debian 12 (Bookworm), and we integrate DuckDB using the following Go modules:

github.com/duckdb/duckdb-go-bindings (v0.1.15, required for DuckDB 1.3.0)
github.com/marcboeker/go-duckdb/v2 (v2.3.0)

We are running into major build and runtime issues with the latest DuckDB version due to prebuilt static libraries (.a files) in duckdb-go-bindings which are retrieved from duckdb github. Here’s a detailed explanation:

The prebuilt static libs for Linux in duckdb-go-bindings v0.1.15 are compiled with GCC 14.2.1 and expect glibc/libstdc++ symbols that are not present in stable Debian 12 (which ships with GCC 12.2.0 and glibc 2.36).

We build and deploy our application on Debian 12 using the system GCC (12.2.0).

When linking with the prebuilt static libs, the linker fails with errors like:

undefined reference to __cxa_call_terminate' /lib/x86_64-linux-gnu/libm.so.6: version GLIBC_2.38' not found
/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found

The official documentation (https://duckdb.org/2025/05/21/announcing-duckdb-130.html#breaking-changes-and-deprecations) says binaries require at least glibc 2.28 (we have 2.36), but this does not address the GCC ABI incompatibility from using a much newer compiler.

Why this is a problem:

Building all static libraries from source is time-consuming and error-prone and we would prefer to avoid this if possible.
We cannot easily upgrade production hosts to GCC 14 or glibc 2.38+ (they are on stable Debian 12, GCC 12.2.0).

This packaging decision effectively blocks users of mainstream Linux LTS distributions from using prebuilt Go bindings without significant extra work.

To Reproduce

Given the above constraints, what is your recommended path forward for projects like ours?

Should we always build our own static libraries from source for each new DuckDB release?

Is there a plan to provide prebuilt static libs for Linux built with a more widely-compatible toolchain (e.g., GCC 12.x, glibc 2.36)?

Is there a recommended way to pin a version or request compatibility in go.mod for downstream users on Debian 12 and similar distros?

Is there any known workaround for this ABI mismatch when using the prebuilt static libs?

Any advice or best practices for maintaining a stable Go integration with DuckDB on Debian LTS releases would be appreciated.

OS:

Debian 12

DuckDB Version:

1.3.0

DuckDB Client:

Golang

Hardware:

No response

Full Name:

Milos Marjanovic

Affiliation:

DS

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a stable release

Did you include all relevant data sets for reproducing the issue?

No - Other reason (please specify in the issue body)

Did you include all code required to reproduce the issue?

• Yes, I have

Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?

• Yes, I have