On Mon, Jun 20, 2022 at 08:42:51AM +1200, Michael Hudson-Doyle wrote: > Ah yes but that patch doesn't actually work in practice. I've been slack on > this :( > > IIRC the problem with https://go-review.googlesource.com/c/go/+/339370 is > that lto causes some of the references in the linked executable to > disappear, meaning cgo can't do the analysis it needs to do. It's a shame > because it's obviously a much cleaner patch... >
However CL281314 has its own problem that causes several packages FTBFS (#982701, #982714, #982720, #982724, #982734) If CL339370 has problem too, can we try another routine? Like disable lto in dh-golang? If I read doko's message right, we are only going to enable lto by default in dpkg-buildflags, not gcc itself. So hacking dh-golang looks more sensible to me. For example adding following line to dh-golang (I didn't test it though): diff --git a/lib/Debian/Debhelper/Buildsystem/golang.pm b/lib/Debian/Debhelper/Buildsystem/golang.pm index 60f725a..02f16fe 100644 --- a/lib/Debian/Debhelper/Buildsystem/golang.pm +++ b/lib/Debian/Debhelper/Buildsystem/golang.pm @@ -369,6 +369,7 @@ sub _set_goproxy { sub _set_cgo_flags { my $bf = Dpkg::BuildFlags->new(); $bf->load_config(); + $bf->set_feature("optimize", "lto", 0) my @flags = ( "CFLAGS", "CPPFLAGS", "CXXFLAGS", "FFLAGS", "LDFLAGS" ); foreach my $flag (@flags) {