Bug#1049392: golang-1.21: FTBFS if dh-golang is installed

[Takahide Nojima]

Dear maintainer,

 I submitted the report of #1055263. I have also identified the
probable cause of this issue and suggested a patch for dh-golang to fix
this problem.

I hope that this patch will be helpful.

Takahide Nojima

Bug#1049392: golang-1.21: FTBFS if dh-golang is installed

[Matthew Gabeler-Lee]

On Tue, 15 Aug 2023, Shengjing Zhu wrote:


So why would you install dh-golang? It's not listed in golang-1.21's
Build-Depends.


To build other packages. Building Go and building packages that use Go 
on the same system doesn't seem weird to me. Is your view that source 
packages only need to be buildable in isolated chroots/containers that 
have just essential and their build-deps installed?


While the policy manual doesn't seem to be explicit on this, the 
existence of the Build-Conflicts field seems to imply that the 
expectation is any breakage is explicitly declared there, and would 
provide a reasonable solution to this IMO.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824495 has a long 
discussion on the merits of different possible policy stances on this. 
https://lists.debian.org/debian-devel/2019/02/msg00204.html continues 
that discussion, though some of the mesages were also CC'd to the bug.


--
-- Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#1049392: golang-1.21: FTBFS if dh-golang is installed

[Matthew Gabeler-Lee]

Source: golang-1.21
Version: 1.21.0-1
Severity: important
Tags: ftbfs

Context: trying to build local golang-1.21 packages against stable (bookworm) 

If dh-golang is installed, building the golang toolchain itself fails tests,
specifically TestCgoLib in src/cmd/nm/nm_cgo_test.go:

--- 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

After much digging and adding printf-y debugging output to the go toolchain,
I eventually tracked this down to dh-golang copying CFLAGS (and related) env
vars to CGO_CFLAGS (etc.).  This notably includes the `-ffile-prefix-map`
flag, which the go toolchain doesn't like, which causes it to put a
"preferlinkext" sigil file in the `.a` file the test generates, which then
makes the `go tool nm` program under test barf, because it doesn't know what
that flag file is.

I've reported the issue with `go tool nm` upstream: 
https://github.com/golang/go/issues/62036

However, I don't think `dh-golang` should be getting pulled in when building
the Go toolchain itself, should it, at least not for setting CGO flags since
I don't think the toolchain uses CGO, so this is only messing with tests?

This also affects golang-1.20, and based on my analysis of the root cause in
the upstream issue, I believe will affect golang-1.19 too, but I have not
directly confirmed that.

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled