Subject: bug#31777: guile-2.2 FTCBFS for mipsel: In procedure load-thunk-from-memory: No such file or directory

From: Rob Browning <[email-masked]>
Date: Sun, 10 Jun 2018 15:10:19 -0500

[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 <[email-masked]> 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