Your message dated Sun, 10 Jun 2018 15:10:19 -0500 with message-id <87vaaqpfmc....@trouble.defaultvalue.org> has caused the report #900203, regarding guile-2.2 FTCBFS for mipsel: In procedure load-thunk-from-memory: No such file or directory to be marked as having been forwarded to the upstream software author(s) bug-gu...@gnu.org
(NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 900203: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900203 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---[If possible, please preserve the 900203-forwarded address in replies] We're currently unable to cross-build guile 2.2 on all of the debian release architectures, which is important given that through make, etc., guile's now part of the core bootstrap set for new architectures. You can see additional information here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900203 and I have been able to reproduce the failure on a debian buster (testing) amd64 host by adding armhf as root: # dpkg --add-architecture armhf # apt build-dep -t buster guile-2.2 # apt install -t buster \ fakeroot \ dpkg-dev \ binutils:armhf \ crossbuild-essential-armhf \ gcc-arm-linux-gnueabihf \ libc-dev:armhf libncurses5-dev:armhf and then building the package as not-root: $ apt source guile-2.2=2.2.3+1-4 $ cd guile-2.2-2.2.3+1 $ DEB_BUILD_PROFILES="cross nocheck" \ DEB_BUILD_OPTIONS="parallel=2 nocheck" \ fakeroot dpkg-buildpackage -B --host-arch=armhf ...which fails with the same error reported in the debian bug: guild compile --target="arm-unknown-linux-gnueabihf" -Wunbound-variable -Wmacro-use-before-definition -Warity-mismatch -Wformat \ -L "/home/rlb/deb/guile/main/module" -L "/home/rlb/deb/guile/main/module" \ -L "/home/rlb/deb/guile/main/guile-readline" \ --from=elisp -o "language/elisp/boot.go" "language/elisp/boot.el" Backtrace: In srfi/srfi-1.scm: 640:9 19 (for-each #<procedure 55b6de6cca00 at scripts/compile.?> ?) In scripts/compile.scm: 251:26 18 (_ _) In system/base/target.scm: 57:6 17 (with-target _ _) In system/base/compile.scm: 139:28 16 (compile-file "language/elisp/boot.el" #:output-file _ # ?) In system/base/language.scm: 110:30 15 (default-environment _) 62:11 14 (lookup-language elisp) In ice-9/boot-9.scm: 2714:10 13 (_ (language elisp spec) _ _ #:ensure _) 2982:16 12 (try-module-autoload _ _) 2312:4 11 (save-module-excursion _) 3002:22 10 (_) In unknown file: 9 (primitive-load-path "language/elisp/spec" #<procedure ?>) In system/base/compile.scm: 165:4 8 (compile-and-load _ #:from _ #:to _ #:env _ #:opts _ # _) 235:18 7 (read-and-compile #<input: language/elisp/boot.el 13> # ?) 183:32 6 (compile-fold (#<procedure compile-tree-il (expr env ?>) ?) In language/elisp/compile-tree-il.scm: 805:5 5 (compile-tree-il (defmacro @ (module symbol) (#{`}# ?)) ?) 705:11 4 (_ _ _) In system/base/compile.scm: 255:6 3 (compile _ #:from _ #:to _ #:env _ #:opts _) 183:32 2 (compile-fold _ #<tree-il (seq (call (@ (language elis?> ?) In language/bytecode/spec.scm: 28:15 1 (bytecode->value #vu8(127 69 76 70 1 1 1 255 0 0 0 0 ?) ?) In unknown file: 0 (load-thunk-from-memory #vu8(127 69 76 70 1 1 1 255 0 ?)) ERROR: In procedure load-thunk-from-memory: In procedure load-thunk-from-memory: No such file or directory Makefile:2267: recipe for target 'language/elisp/boot.go' failed Please let me know if I can help test anything further, and note that it appears possible that the the architecture may be relevant, i.e. from the debian bug: Helmut Grohne <hel...@subdivi.de> writes: > Initially, I thought the failure was 100% reproducible for any > architecture. That doesn't seem to be the case. Let me try building > guile-2.2 for most release architecture with sbuild: > > arm64: successful > armel: ftcbfs, ftcbfs > armhf: ftcbfs, ftcbfs > mips: multiarch skew linux-libc-dev > mips64el: successful > mipsel: multiarch skew linux-libc-dev > powerpc: ftcbfs, ftcbfs > ppc64el: successful > s390x: ftcbfs > > I ran each ftcbfs build twice to rule out the possibility of a random > ftcbfs. So we have a non-random ftcbfs for some architectures. I'm a bit > surprised about s390x here as it is the only failing 64bit architecture. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
--- End Message ---
