What version of Go are you using (go version)?

$ go version
1.21.0

Does this issue reproduce with the latest release?

1.21.0 is the latest release. The problematic code is still present on master. This also reproduces in go 1.20, and probably in go 1.19 (based on the backport status of the CL below, though I have not directly confirmed that)

What operating system and processor architecture are you using (go env)?

Linux amd64

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/cheetah/.cache/go-build"
GOENV="/home/cheetah/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/data/cheetah/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/data/cheetah/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.19"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.19/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19.8"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build505240055=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Trying to build go from Debian source package. The Debian packaging sometimes, as part of their reproducible builds effort, causes some extra CGO_CFLAGS (and CGO_CXXFLAGS) to be set in the environment in addition to what is above. Notably this includes -ffile-prefix-map=/some/source/dir=..

Note that while Debian-specific details are the particular way I discovered this, the underlying issue -- that the go linker can generate .a files that go tool nm cannot read -- is not specific to that scenario.

The presence of this flag causes the .a generation for the TestCgoLib test, building a library with -buildmode=archive, to include a preferlinkext empty sigil file (see #58619 and https://go.dev/cl/475375). However go tool nm is unable to process this sigil within the .a file, and so it errors out when trying to read the symbols during the test.

This happens because the .a entry listing ends up in this switch case:

After that it tries to process the .a file with the ELF and other "openers", which of course all fail, and so it finally fails with unrecognized object file at:

What did you expect to see?

go tool nm and its tests should work even if the preferlinkext flag ends up in a .a file

What did you see instead?

go tool nm and its tests fail if the preferlinkext flag ends up in a .a file, causing the tests to fail:

--- FAIL: TestCgoLib (2.19s)
    nm_test.go:264: go tool nm: exit status 1
        open /tmp/TestGoLib2084668406/gopath/src/mylib/mylib.a: unrecognized object file

I think it should be easy enough to recognize the flag file in the switch case above and just skip it?

cc @thanm who wrote the CL above that introduced this flag file

A Dockerfile that can be used to reproduce the issue in isolation:

FROM debian:bookworm

RUN apt-get update
RUN apt-get -y --no-install-recommends install build-essential
RUN apt-get -y --no-install-recommends install git
RUN apt-get -y --no-install-recommends install git-buildpackage
RUN apt-get -y --no-install-recommends install debhelper-compat=13 golang-go netbase

# commenting out the next line line will cause the problem CGO_CFLAGS to not be set and thus the build will pass
RUN apt-get -y --no-install-recommends install dh-golang

RUN git clone --branch=golang-1.21 --filter=blob:none https://salsa.debian.org/go-team/compiler/golang.git
WORKDIR /golang
RUN gbp buildpackage -b -uc -us -rfakeroot --git-ignore-new || true
RUN cp -v /tmp/nm.test /tmp/mylib.a /