bug#41160: sbcl-cffi-libffi: Fails to build on ARM
Fails to build on powerpc64le with a very similar error, log attached. tldr: "error: ‘FFI_SYSV’ undeclared" (I'm assuming sbcl-cffi-0.24.1 is just a newer name/version of sbcl-cffi-libffi) dx7fab1f6fm5w95maajxcy0r9jv3xy-sbcl-cffi-0.24.1.drv.bz2 Description: Build log of sbcli-cffi-0.24.1
bug#56680: go-1.16.15 build fails in check phase on powerpc64le
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 <= 10 --- FAIL: TestTrivialExecutablePIE (0.61s) shared_test.go:484: file too large: got 202824, want <= 10 Full build log: https://dpaste.org/iWfL0
bug#56680: go-1.16.15 build fails in check phase on powerpc64le
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?
bug#56680: go-1.16.15 build fails in check phase on powerpc64le
[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? signature.asc Description: PGP signature
bug#56680: go-1.16.15 build fails in check phase on powerpc64le
[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 [0] v12
bug#57134: powerpc64le: gst-plugins-good build link error on aalib (libgstaasink.so)
Building gst-plugins-good on powerpc64le (Talos II machine) produces a link error related to aalib. Commenting out the 'aalib' input makes the build succeed. Relevant snippet from the build log below. --8<---cut here---start->8--- [444/851] Linking target ext/aalib/libgstaasink.so FAILED: ext/aalib/libgstaasink.so gcc -o ext/aalib/libgstaasink.so ext/aalib/libgstaasink.so.p/gstaasink.c.o ext/aalib/libgstaasink.so.p/gstaatv.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libgstaasink.so -Wl,-Bsymbolic-functions -Wl,-rpath=/gnu/store/ypfbdcb16s2mir7x51hv0jckcq8rl15b-gst-plugins-good-1.18.5/lib /gnu/store/3zfl42ll99vhf8dg1na6vwp7iqn2439q-gst-plugins-base-1.18.5/lib/libgstvideo-1.0.so /gnu/store/s4hh37b9z35ik9mv5vsxyfdx4pdi84py-gstreamer-1.18.5/lib/libgstbase-1.0.so /gnu/store/s4hh37b9z35ik9mv5vsxyfdx4pdi84py-gstreamer-1.18.5/lib/libgstreamer-1.0.so /gnu/store/3d194piqkas8gv66qa9hawa6qa115i6a-glib-2.70.2/lib/libgobject-2.0.so /gnu/store/3d194piqkas8gv66qa9hawa6qa115i6a-glib-2.70.2/lib/libglib-2.0.so -laa -Wl,--end-group ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aarender.o): in function `aa_renderpalette': (.text+0x798): undefined reference to `pow' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o):(.text+0xe8): undefined reference to `curs_set' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o):(.text+0x130): undefined reference to `wrefresh' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o):(.text+0x18c): undefined reference to `wmove' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o):(.text+0x1d4): undefined reference to `waddnstr' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o): in function `curses_init': (.text+0x250): undefined reference to `initscr' ld: (.text+0x27c): undefined reference to `termattrs' ld: (.text+0x2d4): undefined reference to `intrflush' ld: (.text+0x344): undefined reference to `wclear' ld: (.text+0x354): undefined reference to `intrflush' ld: (.text+0x360): undefined reference to `wrefresh' ld: (.text+0x3a4): undefined reference to `endwin' ld: (.text+0x46c): undefined reference to `wclear' ld: (.text+0x47c): undefined reference to `intrflush' ld: (.text+0x488): undefined reference to `wrefresh' ld: (.text+0x50c): undefined reference to `endwin' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurses.o):(.toc+0x0): undefined reference to `stdscr' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x2c): undefined reference to `nodelay' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x70): undefined reference to `wgetch' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x104): undefined reference to `nodelay' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x224): undefined reference to `initscr' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x254): undefined reference to `cbreak' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x25c): undefined reference to `noecho' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x264): undefined reference to `nonl' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x27c): undefined reference to `keypad' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x330): undefined reference to `keypad' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x340): undefined reference to `nodelay' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x358): undefined reference to `nocbreak' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x360): undefined reference to `echo' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x370): undefined reference to `nl' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x3a8): undefined reference to `intrflush' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x3b4): undefined reference to `wclear' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylxnvl6-aalib-1.4rc5/lib/../lib/libaa.a(aacurkbd.o):(.text+0x3c0): undefined reference to `wrefresh' ld: /gnu/store/xq3kvsvfmbi1hlr6ilpcw8zi7ylx
bug#57303: powerpc64le: rust build failure is bottleneck for many packages
I use a Talos II machine as my daily driver and slowly migrating as many packages to GUIX along the way. The kernel I am running comes fromm https://archlinuxpower.org/ For many packages, rust is getting to be the bottleneck as a dependency that does not build. From what I can see there's a whole chain of rust dependencies going back to rust@1.39.0 which then ultimately fails with: --8<---cut here---start->8--- (16/112) BUILDING bitflags v1.1.0 /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc rustc-1.39.0-src/vendor/bitflags/src/lib.rs -o output/rustc-build/libbitflags-1_1_0.rlib --crate-name bitflags --crate-type rlib -C emit-depfile=output/rustc-build/libbitflags-1_1_0.rlib.d --crate-tag 1_1_0 -g --cfg debug_assertions -O -L output -L output/rustc-build --cfg bitflags_const_fn (17/112) BUILDING cc v1.0.35 /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc rustc-1.39.0-src/vendor/cc/src/lib.rs -o output/rustc-build/libcc-1_0_35.rlib --crate-name cc --crate-type rlib -C emit-depfile=output/rustc-build/libcc-1_0_35.rlib.d --crate-tag 1_0_35 -g --cfg debug_assertions -O -L output -L output/rustc-build /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc rustc-1.39.0-src/src/librustc_llvm/build.rs --crate-name build --crate-type bin -o output/rustc-build/build_rustc_llvm_run -L output/rustc-build -g -L output --extern build_helper=output/rustc-build/libbuild_helper-0_1_0.rlib --extern cc=output/rustc-build/libcc-1_0_35.rlib --edition 2018 /tmp/guix-build-rust-1.39.0.drv-0/mrustc/output/rustc-build/build_rustc_llvm_run thread 'main' panicked at 'assertion failed: `(left == right)` left: `1`, right: `0`', rustc-1.39.0-src/vendor/hashbrown/src/raw/mod.rs:1086:59 Process was terminated with signal 6 --8<---cut here---end--->8--- The line in =mod.rs= points to an assertion in some sort of table iterator. Way over my head. I know rust runs on powerpc64le because I have a binary version 1.62 installed through https://archlinuxpower.org/ Is anyone familiar with this working on rust on powerpc64 for the powerpc64le-linux system?
bug#57303: powerpc64le: rust build failure is bottleneck for many packages
For reference: this is the mrustc bug that needs resolving https://github.com/thepowersgang/mrustc/issues/194
bug#57303: powerpc64le: rust build failure is bottleneck for many packages
[Efraim Flashner]: Is anyone familiar with this working on rust on powerpc64 for the powerpc64le-linux system? About 2 months ago I spent some time and got the rust bootstrap working for riscv64-linux. I would suggest looking at the staging branch since there the rust bootstrap version is at 1.54. Ah, I didn't even think of that, thanks! Will try that.
bug#57303: powerpc64le: rust build failure is bottleneck for many packages
[Marcel van der Boom]: [Efraim Flashner]: About 2 months ago I spent some time and got the rust bootstrap working for riscv64-linux. I would suggest looking at the staging branch since there the rust bootstrap version is at 1.54. Ah, I didn't even think of that, thanks! Will try that. Unfortunately, it fails with the exact same error
bug#57402: FreeCAD build fails to configure / Qt5WebKitWidgets related.
The freecad package fails to build. The following error is the relevant part from the log. I'm on powerpc64le, which is usually somewhat problematic in building. Not sure if that is relevant for this issue though. --8<---cut here---start->8--- CMake Error at cMake/FreeCAD_Helpers/SetupQt.cmake:28 (find_package): By not providing "FindQt5WebKitWidgets.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Qt5WebKitWidgets", but CMake did not find one. Could not find a package configuration file provided by "Qt5WebKitWidgets" with any of the following names: Qt5WebKitWidgetsConfig.cmake qt5webkitwidgets-config.cmake Add the installation prefix of "Qt5WebKitWidgets" to CMAKE_PREFIX_PATH or set "Qt5WebKitWidgets_DIR" to a directory containing one of the above files. If "Qt5WebKitWidgets" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): CMakeLists.txt:69 (include) -- Configuring incomplete, errors occurred! --8<---cut here---end--->8---
bug#57402: FreeCAD build fails to configure / Qt5WebKitWidgets related.
[Thiago Jung Bauermann]: Is this on master, or core-updates? On master, freecad-0.20.1 builds fine on x86_64-linux, but on powerpc64le-linux it doesn't get built because of a dependency failure: I get the same build failure in 'hdf4-alt' as you posted above. This is in the check phase on 'master' indeed. When building using '--without-tests=hdf4-alt' the error I submitted as bug appears. I should have mentioned that.
bug#57134: [PATCH] FIX: Skip `aalib' input on target ppc64le
* gstreamer.scm (gst-plugins-good): skip aalib input on ppc64le Linker errors out for unknown reasons. The ascii art is imho not important enough to skip the whole package from being included for ppc64le. --- gnu/packages/gstreamer.scm | 75 -- 1 file changed, 39 insertions(+), 36 deletions(-) diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm index 916ab2e990..156ef4eda4 100644 --- a/gnu/packages/gstreamer.scm +++ b/gnu/packages/gstreamer.scm @@ -687,42 +687,45 @@ (define libsoup python-wrapper xorg-server-for-tests)) (inputs - (list aalib - bzip2 - cairo - flac - (librsvg-for-system) - glib - glib-networking - glu - gtk+ - jack-2 - lame - libavc1394 - libcaca - libdv - libgudev - libiec61883 - libjpeg-turbo - libpng - libshout - libsoup - libvpx - libx11 - libxdamage - libxfixes - libxext - libxshmfence - mesa - mpg123 - orc - pulseaudio - speex - taglib - twolame - v4l-utils - wavpack - zlib)) + (append + ;; linking aalib on ppc64le errors out; + ;; ascii isn't that important to skip the whole package for it. + (if (not target-ppc64le?) (list aalib) '()) + (list bzip2 +cairo +flac +(librsvg-for-system) +glib +glib-networking +glu +gtk+ +jack-2 +lame +libavc1394 +libcaca +libdv +libgudev +libiec61883 +libjpeg-turbo +libpng +libshout +libsoup +libvpx +libx11 +libxdamage +libxfixes +libxext +libxshmfence +mesa +mpg123 +orc +pulseaudio +speex +taglib +twolame +v4l-utils +wavpack +zlib))) (propagated-inputs (list gstreamer gst-plugins-base)) (synopsis "GStreamer plugins and helper libraries") -- 2.38.1
bug#56680: go-1.16.15 build fails in check phase on powerpc64le
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?
bug#57134: (no subject)
This has been resolved with the 1.22.2 update. close quit
bug#57134: (no subject)
reopen 57134 quit Apologies for the noise. I had a manifest in place working around the bug, but unfortunately the bug is still there.
bug#57402: FreeCAD build fails to configure / Qt5WebKitWidgets related.
This still fails for me, same error. To be clear, substitutable means there is a binary available from one of the substituation servers? If so, guix is not using it as it tries to build freecad, starting with a configure, where it then fails. What am I missing? I am using a manifest where some of the dependencies of freecad skip tests, as in: (options->transformation '((without-tests . "ffmpeg") (without-tests . "hwloc") (without-tests . "hdf4-alt") (without-tests . "python-pandas") (without-tests . "gst-plugins-bad") (without-tests . "gtk") (without-tests . "qtbase"))) these are needed for a number of packages on ppc64le.
bug#57402: webkitgtk-with-libsoup2 fails to build on powerpc64le, breaking freecad
The latter is the aalib package which is for ascii art. See https://issues.guix.gnu.org/57134 for my proposed solution. (that is, just leaving it out) That is not sufficient however to get freecad to build, the original error reported above still occurs then.
bug#57134: [PATCH] powerpc64le: gst-plugins-good build link error on aalib (libgstaasink.so)
close 57134 quit This is fixed with https://git.savannah.gnu.org/cgit/guix.git/commit/?id=fafd3caef0d51811a5da81d6061789e2908b0dac See: https://issues.guix.gnu.org/65646
bug#57402: webkitgtk-with-libsoup2 fails to build on powerpc64le, breaking freecad
I think this issue was wrongly retitled. While the webkitgtk-with-libsoup2 *was* also an issue (now fixed) the configure phase error as originally reported (reproduced below for clarity) is still there. CMake Error at /gnu/store/sigy8gnn715y6219syqh2a2fr70l5vly-qtbase-5.15.10/lib/cmake/Qt5/Qt5Config.cmake:28 (find_ Could not find a package configuration file provided by "Qt5WebEngineWidgets" with any of the following names: Qt5WebEngineWidgetsConfig.cmake qt5webenginewidgets-config.cmake Add the installation prefix of "Qt5WebEngineWidgets" to CMAKE_PREFIX_PATH or set "Qt5WebEngineWidgets_DIR" to a directory containing one of the above files. If "Qt5WebEngineWidgets" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): cMake/FreeCAD_Helpers/SetupQt.cmake:31 (find_package) CMakeLists.txt:78 (include) -- Configuring incomplete, errors occurred!
bug#70771: GUIX pull fails to build guix derivation
Copied output as suggested below
guix https://git.savannah.gnu.org/git/guix.git aa9ac25
substitute: updating substitutes from
'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from
'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...
100.0%
substitute: updating substitutes from
'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...
100.0%
substitute: updating substitutes from
'https://bordeaux.guix.gnu.org'... 100.0%
building
/gnu/store/0qcd9hmrjf08rh4ym5vwkprli4dzryjh-guile-git-0.7.0.drv...
building
/gnu/store/0ygd9p76xw64xrzq4m527f6m0va1ilvq-nss-3.99.0.drv...
The following build is still in progress:
/gnu/store/0ygd9p76xw64xrzq4m527f6m0va1ilvq-nss-3.99.0.drv
building
/gnu/store/mbn9c0nrds9lsph3wk9izrydzimny4q1-guix-daemon-1.4.0-18.4c94b9e.drv...
The following build is still in progress:
/gnu/store/0ygd9p76xw64xrzq4m527f6m0va1ilvq-nss-3.99.0.drv
| 'check' phasebuild-log 3160471 101
[ OK ] Pkcs11ModuleTest.ListSlots (0 ms)
[ RUN ] Pkcs11ModuleTest.PublicCertificatesToken
- 'check' phasebuild-log 3160471 101
[ OK ] Pkcs11ModuleTest.ListSlots (0 ms)
[ RUN ] Pkcs11ModuleTest.PublicCertificatesToken
\ 'check' phaseBacktrace:
14 (primitive-load
"/gnu/store/b57d9jzzr4nrpjzgg95j063pkkxkp1a3-compute-guix-derivation")
In ice-9/eval.scm:
155:9 13 (_ _)
159:9 12 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# (guile-u?> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 11 (with-fluid* _ _ _)
152:2 10 (with-fluid* _ _ _)
In ./guix/store.scm:
2182:24 9 (run-with-store # 3f93b693a0a0> #
?)
2010:8 8 (_ #)
In ./guix/gexp.scm:
299:22 7 (_ #)
1205:2 6 (_ #)
1072:2 5 (_ #)
913:4 4 (_ #)
In ./guix/store.scm:
2067:12 3 (_ #)
1405:5 2 (map/accumulate-builds # 3f93b693a0a0> # ?)
1421:15 1 (_ #
("/gnu/store/mbn9c0nrds9lsph3wk9izrydzimny4q1-guix-daemo?" ?) ?)
1421:15 0 (loop #f)
./guix/store.scm:1421:15: In procedure loop:
ERROR:
1. &store-protocol-error:
message: "build of
`/gnu/store/0ygd9p76xw64xrzq4m527f6m0va1ilvq-nss-3.99.0.drv'
failed"
status: 100
guix pull: error: You found a bug: the program
'/gnu/store/b57d9jzzr4nrpjzgg95j063pkkxkp1a3-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"aa9ac252206615713ab988d7068da9e14a9bccc0"; system:
"powerpc64le-linux";
host version: "e5c130c0f90a7dacc8d223eee494a1b1105dd94a";
pull-version: 1).
--
Marcel van der Boom → mar...@van-der-boom.nl
bug#70771: nss 3.99 test failure
This issue has been resolved. If I recall correctly the patch was allowing the tests to have some more time. The build now succeeds on my machines. (powerpc64le)
