Problem compiling with golang. #115

Closed
opened 2022-05-14 06:35:08 +02:00 by patlefort · 6 comments

Hi, I can't compile snapd with go:

/usr/lib/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
lto1: fatal error: bytecode stream in file ‘/tmp/go-link-2007900548/000000.o’ generated with LTO version 11.0 instead of the expected 12.0
compilation terminated.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

I think something needs to be recompiled with GCC 12, however I'm not sure what exactly. I tried compiling and installing go myself and I still get the error.

Hi, I can't compile snapd with go: ``` /usr/lib/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1 lto1: fatal error: bytecode stream in file ‘/tmp/go-link-2007900548/000000.o’ generated with LTO version 11.0 instead of the expected 12.0 compilation terminated. lto-wrapper: fatal error: gcc returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status ``` I think something needs to be recompiled with GCC 12, however I'm not sure what exactly. I tried compiling and installing go myself and I still get the error.
Contributor

Yeah, I think we need to recompile all packages once with GCC 12 and also bump the pkgrel. Is this possible @anonfunc?

Yeah, I think we need to recompile all packages once with GCC 12 and also bump the pkgrel. Is this possible @anonfunc?
Owner

Probably not all, but a few have these problems because gcc is not mandatory to list as makedep because its in base-devel (which is fine), but ALHP did not take that into account until https://git.harting.dev/ALHP/ALHP.GO/commit/f190902b412df4bffee6c553fbd179a67557cb02.

I'll try to figure out what causes your specific issue, so that we can queue it with gcc 12 again.

Probably not all, but a few have these problems because gcc is not mandatory to list as makedep because its in base-devel (which is fine), but ALHP did not take that into account until https://git.harting.dev/ALHP/ALHP.GO/commit/f190902b412df4bffee6c553fbd179a67557cb02. I'll try to figure out what causes your specific issue, so that we can queue it with gcc 12 again.
anonfunc added the bug label 2022-05-14 21:48:06 +02:00
Author

Looks like the lastest update to go fixed the issue.

Looks like the lastest update to go fixed the issue.
Contributor

@anonfunc btw the "1to1" sounds like we/Arch are/is using -flto-partition=1to1 atm? 🤔

That would be quite suboptimal compared to the -flto-partition=dynamic which is the standard.

However #117 contains a patch to set it to -flto-partition=one which can cross boundaries between sourcecode objects in the first pass and supposedly avoid some issues with compiling programs - with the drawback of loading the full program into memory and do single thread processing on it.

@anonfunc btw the "1to1" sounds like we/Arch are/is using `-flto-partition=1to1` atm? 🤔 That would be quite suboptimal compared to the `-flto-partition=dynamic` which is the standard. However #117 contains a patch to set it to `-flto-partition=one` which can cross boundaries between sourcecode objects in the first pass and supposedly avoid some issues with compiling programs - with the drawback of loading the full program into memory and do single thread processing on it.
Owner

We and Archlinux are using -flto-partition's default. You can always check their makepkg.conf in devtools to know what they are currently using, since this config gets used by all build-helpers (and so the packagers; it's also the basis for our own makepkg.conf).

We and Archlinux are using `-flto-partition`'s default. You can always check [their makepkg.conf](https://gitlab.archlinux.org/archlinux/devtools/-/blob/master/makepkg-x86_64.conf#L48=) in devtools to know what they are currently using, since this config gets used by all build-helpers (and so the packagers; it's also the basis for our own makepkg.conf).
Contributor

Ah thanks. I was under the impression that the makepkg.conf of arch itself was beeing used (which is part of the pacman package).

Thanks for the clarification!

So Arch/we should be using the default which is -flto-partition=dynamic.

Ah thanks. I was under the impression that the makepkg.conf of arch itself was beeing used (which is part of the pacman package). Thanks for the clarification! So Arch/we should be using the default which is `-flto-partition=dynamic`.
Sign in to join this conversation.