Hi Janneke! Jan Nieuwenhuizen <jann...@gnu.org> skribis:
>> Ludovic Courtès <l...@gnu.org> skribis: >> >>> On commit 9b4c3c675c05870e5983c21ce4ff944e0b0bc2fa of ‘core-updates’, >>> mescc-tools fails tests, with generated binaries segfaulting: >>> >>> $ ./pre-inst-env guix build mescc-tools >>> >>> […] >>> >>> + . ./sha256.sh >>> ++ set -ex >>> ++ ./bin/get_machine >>> + ./bin/M1 -f test/test3/defs -f test/test3/lisp.s --BigEndian >>> --architecture knight-native -o test/test3/hold >>> + '[' amd64 = amd64 ']' >>> + ./test/results/test1-binary >>> + ./bin/hex2 -f elf_headers/elf32.hex2 -f test/test2/hold --LittleEndian >>> --architecture x86 --BaseAddress 0x8048000 -o test/results/test2-binary >>> --exec_enable >>> test/test1/hello.sh: line 37: 125 Segmentation fault >>> ./test/results/test1-binary < test/test1/hex0.hex0 > test/test1/proof1 [...] >> Should we upgrade instead? If we do, what’s the potential for breakage? >> Should ‘mes-rb5’ be kept on an older version? > > We could try that, I really can't tell if upgrading to 1.1.0 creates > a different mes binary. I took this route and everything went well, and we can now build ‘bootstrap-tarballs’ on x86_64-linux. I ended up doing additional changes: e2690a8eb2 gnu: mes-rb5: Remove. da32015db0 gnu: mes-minimal-stripped: Explicitly disallow references. 5510e1c483 gnu: mes: Remove 0.19. 81096caf7d gnu: mes: Switch to Guile 3.0. 114a9f1f80 gnu: mescc-tools: Update to 1.2.0. 0b9da8b5a2 gnu: m2-planet: Update to 1.8.0. 8b627a7701 gnu: mes-minimal: Remove unused variable. Removing ‘mes-rb5’ was a bit disheartening but I guess it’d have to be updated to the current tool versions. I removed Mes 0.19 because it failed to build with Guile 3.0 and didn’t appear to be needed any longer. Let me know if you think I did anything wrong! Thanks, Ludo’.
