On 20.06.22 05:50, Michael Hudson-Doyle wrote:
On Mon, 20 Jun 2022 at 14:59, Shengjing Zhu <z...@debian.org> wrote:
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)
I think that was a broken version of the patch -- the packages those bugs
affect build fine in Ubuntu now afaics -- but I haven't checked explicitly.
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) {
If that works, it might be a better option for now indeed.
yes, that looks like a good solution.
