Ludovic Courtès writes: Hello,
> Ludovic Courtès <[email protected]> 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 > > [...] How weird! I wonder what changed... >> builder for >> `/gnu/store/lir8pmc63k1bcj4ml9gsx1769aw9ndj2-mescc-tools-0.7.0.drv' failed >> with exit code 1 > > I found that this upstream commit, which made it in version 1.1.0, fixes > the segfault: > > commit e633669dfdf16f503a7d740b9058e343536533b4 > Author: nimaje <[email protected]_channel> > Date: Thu Oct 15 19:12:18 2020 -0400 > > Fix ELF headers to be more well behaved [..] > 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. Greetings, Janneke -- Jan Nieuwenhuizen <[email protected]> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
