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