bug#49515: [core-updates] mescc-tools tests fail

[Jan Nieuwenhuizen <janneke@gnu.org>]

Ludovic Courtès writes:

Hello,

> Ludovic Courtès <ludo@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
>
> [...]

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 <nimaje@bootstrappable.irc_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 <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com