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.
Cheers,
mwh
