bug#50346: core-updates-frozen: strace 5.13 fails "make check" on AArch64

[Simon South]

Bengt Richter <bokr@bokr.com> writes:
> A proper configurability, ISTM, would be preferable to any other form
> of more general filtering.

I agree with you on the need to be cautious around modifying test cases
but I'm not sure I follow you otherwise.  What would "proper
configurability" look like in this case?

The change I'm proposing here narrows the two test cases so they test
only what appears to have been intended, i.e. that strace can capture
readlink(at) system calls and that it reports them in the format
expected by the developers.  It does not affect other test cases or the
test suite as a whole.

The obvious alternative would be to modify the test cases' expected
output to match what is actually generated, but this could have the side
effect of tying the package to Linux and perhaps to specific versions of
glibc.

That said I'm still not sure why this additional syscall is being made
in the first place, only that it appears to originate from glibc's
"_dl_get_origin" function[0].  If I build strace from source "manually"
the tests complete fine without modification.  I presume the extra call
has to do with the fact Guix builds strace inside a container; does
anyone know how this could be affecting the way programs are loaded?

-- 
Simon South
simon@simonsouth.net

[0] See e.g. glibc's sysdeps/unix/sysv/linux/dl-origin.c for the x86-64
    case, as well as "_dl_non_dynamic_init" in elf/dl-support.c, which
    seems to be the only place it is called.