ALHP/ALHP.GO

Fork 9

Problem compiling with golang. #115

New Issue

Closed

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

patlefort commented

2022-05-14 06:35:08 +02:00

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.

RubenKelevra commented

2022-05-14 12:28:34 +02:00

Contributor

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

anonfunc commented

2022-05-14 21:47:51 +02:00

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 f190902b41.

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.

👍 1

anonfunc added the

bug

label 2022-05-14 21:48:06 +02:00

patlefort commented

2022-05-14 23:46:07 +02:00

Author

Looks like the lastest update to go fixed the issue.

👍 1

patlefort closed this issue

2022-05-14 23:46:07 +02:00

RubenKelevra commented

2022-05-15 11:00:38 +02:00

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.

anonfunc commented

2022-05-15 13:48:12 +02:00

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

RubenKelevra commented

2022-05-16 19:09:09 +02:00

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`.