During the check phase of building go-1.16.15 (as dependency of ungoogled-chromium) a failure occurs: https://dpaste.org/ib5CZ : --- FAIL: TestTrivialExecutable (3.43s) shared_test.go:484: file too large: got 202752, want <= 100000 --- FAIL: TestTrivialExecutablePIE (0.61s) shared_test.go:484: file too large: got 202824, want <= 100000 Full build log: https://dpaste.org/iWfL0
I see that the full build log expired on the paste site. Is any additional info needed here, other than the excerpt of the log? I suspect the check error is a safety precaution to ensure executables are of reasonable size, but reasonable is perhaps a bit different on the POWER9 platform?
[-- Attachment #1: Type: text/plain, Size: 848 bytes --] On Thu, Aug 04, 2022 at 06:24:47PM +0200, Marcel van der Boom wrote: > > I see that the full build log expired on the paste site. > > Is any additional info needed here, other than the excerpt of the log? > > I suspect the check error is a safety precaution to ensure executables are > of reasonable size, but reasonable is perhaps a bit different on the POWER9 > platform? I'm currently working on bootstrapping go-1.17.11 directly from gccgo, so we'd be able to skip 1.16 entirely. Currently it works on x86_64-linux but not on riscv64-linux. If you want to test something like that on powerpc64le that'd be great. -- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #1: Type: text/plain, Size: 377 bytes --] [Efraim Flashner]: > I'm currently working on bootstrapping go-1.17.11 directly from > gccgo, > so we'd be able to skip 1.16 entirely. Currently it works on > x86_64-linux but not on riscv64-linux. If you want to test > something > like that on powerpc64le that'd be great. Sure, can you point me in the right direction and get me started on what would be useful for you? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #1: Type: text/plain, Size: 959 bytes --] On Thu, Aug 04, 2022 at 11:02:53PM +0200, Marcel van der Boom wrote: > > [Efraim Flashner]: > > I'm currently working on bootstrapping go-1.17.11 directly from gccgo, > > so we'd be able to skip 1.16 entirely. Currently it works on > > x86_64-linux but not on riscv64-linux. If you want to test something > > like that on powerpc64le that'd be great. > > Sure, can you point me in the right direction and get me started on what > would be useful for you? Looking at the package definitions for go it looks like the inputs and native-inputs need to be cleaned up some, but for our purposes I think just removing the native-inputs field completely from 1.17 should try to make go-1.17 build with gccgo. Then try to build go@1.17. -- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
[Efraim Flashner]: > [...] > just removing the native-inputs field completely from 1.17 > should try to > make go-1.17 build with gccgo. Then try to build go@1.17. That does indeed start a gccgo build and fails after a while with this: ( https://dpaste.org/3UwS2 has more details) starting phase `build' Building Go cmd/dist using /gnu/store/imii98jzv6jhgyk4k6mkagyhksjwn0rr-gccgo-10.3.0. (go1.14.6 gccgo (GCC) 10.3.0 linux/ppc64le) Building Go toolchain1 using /gnu/store/imii98jzv6jhgyk4k6mkagyhksjwn0rr-gccgo-10.3.0. Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1. /tmp/guix-build-go-1.17.11.drv-0/source/src/internal/abi/abi.go:37:7: internal compiler error: '(*RegArgs).Dump': nil register for value: v13 = SelectN <mem> [0] v12
Looking at https://git.savannah.gnu.org/cgit/guix.git/commit/?id=024a8b39957203f3a3cb93c87746c35635b81e57 it might make sense to do the same for the 'powerpc64le' target as well?