Go version

go version go1.25.0 darwin/arm64

same problem observed on go1.24.5 darwin/arm64

Output of go env in your module/workspace:

AR='ar'
CC='clang'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/orian/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/orian/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/xs/3v6gwv_x7tdggvj69fn3n6kw0000gn/T/go-build3997601179=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/orian/workspace/ducks/go.mod'
GOMODCACHE='/Users/orian/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/orian/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/orian/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.25.0'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

create simple program that imports DucksDB library:

package main

import (
    "fmt"
    _ "github.com/marcboeker/go-duckdb/v2"
)

func main() {
    fmt.Println("Hello ducks.")
}

run it through go run but fail to build it through go build

What did you see happen?

# github.com/orian/ducks
/usr/local/go/pkg/tool/darwin_arm64/link: /usr/local/go/pkg/tool/darwin_arm64/link: combining dwarf failed: no room to add dwarf info. Need at least 1112 padding bytes, found 904

What did you expect to see?

A binary to compile.

Comment From: cagedmantis

@golang/compiler

Comment From: cherrymui

What version of macOS are you using? And the C toolchain version (Xcode version, and cc -v and ld -v)? Thanks.

This builds fine on my machine with macOS 15.6 and Apple clang version 17.0.0 (clang-1700.0.13.5), ld-1167.5.

Comment From: orian

  • macOS 15.6
  • Xcode version 16.4
$ cc -v
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

$ ld -v
@(#)PROGRAM:ld PROJECT:ld-1167.5
BUILD 01:45:05 Apr 30 2025
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
will use ld-classic for: armv6 armv7 armv7s i386 armv6m armv7k armv7m armv7em
LTO support using: LLVM version 17.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 17.0.0 (tapi-1700.0.3.5)
  • go was installed through dmg installer

This looks for me like quite standard installation, nothing fancy.

Comment From: cherrymui

It seems you have the same version as mine, but I'm not able to reproduce. What is your version of dsymutil (dsymutil -v)?

What version of github.com/marcboeker/go-duckdb/v2 do you import?

Also, could you try clear the build cache and see if makes any difference?

Comment From: orian

$ dsymutil -v
Homebrew LLVM version 19.1.7
  Optimized build.

and duckdb:

github.com/marcboeker/go-duckdb/v2 v2.3.5

I've got go cache from: go env GOCACHE and removed the directory. It didn't not help. I've recreated a cache once more to be sure. I'll reinstall the go (didn't help).

Comment From: cherrymui

What does cc --print-prog-name dsymutil print? And $(cc --print-prog-name dsymutil) -v?

If this is not the Apple one, it would be good to use the Apple one (e.g. Apple LLVM version 17.0.0). Homebrew installed tools have had issues from time to time being not compatible with Apple tools.

Comment From: orian

I believe i have one from Xcode:

$ cc --print-prog-name dsymutil
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil

$ $(cc --print-prog-name dsymutil) -v
Apple LLVM version 17.0.0
  Optimized build.

i'll poke around homebrew

Comment From: orian

@cherrymui after your suggestion i've got it, let me leave a comment explaining for anyone in a future. I've listed all packages installed by homebrew, my eyes were cought by llvm - suprise, why? removing it fixed my go build.

great thanks for help

$ brew  list
==> Formulae
binutils    ccache      gettext     helmfile    k9s     libevent    libtasn1    llvm        nasm        openssl@3   python@3.11 unbound     zstd
blake3      cmake       gmp     hiredis     krb5        libgcrypt   libtool     lz4     nettle      p11-kit     python@3.13 xxhash
brotli      findutils   gnutls      icu4c@76    kubectx     libgpg-error    libunistring    m4      ninja       pcre2       readline    xz
btop        fmt     grep        jq      kubernetes-cli  libidn2     libxml2     mpdecimal   nvm     pkgconf     rustup      yq
ca-certificates fzf     helm        just        lazydocker  libnghttp2  libxmlsec1  mprocs      oniguruma   postgresql@14   sqlite      z3

==> Casks
clickhouse  orbstack

$ brew remove llvm
Uninstalling /opt/homebrew/Cellar/llvm/19.1.7_1... (8,107 files, 1.9GB)
==> Autoremoving 2 unneeded formulae:
python@3.13
z3
Uninstalling /opt/homebrew/Cellar/z3/4.14.1... (120 files, 32.7MB)
Uninstalling /opt/homebrew/Cellar/python@3.13/3.13.2... (3,375 files, 67.3MB)

Comment From: cherrymui

Probably I should have asked clang -v and clang --print-prog-name dsymutil, as the Go toolchain invokes clang by default on macOS.

Thanks for finding out the cause! If removing llvm ever becomes a problem, you could set your path to prefer /usr/bin/clang over the Homebrew one, or set CC=/usr/bin/clang when running go build.