On +2021-09-03 10:00:33 -0400, Simon South wrote: > Bengt Richter <b...@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.
Well, that would be the point :) I.e., to move the customizations into .conf files and out of test-suite sources. > > 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? > I did not realize there were mods to strace itself affecting this. I thought it was about somehow filtering its output to fool tests, sorry. With strace variants maybe "proper configurability" should have to consider strace versions also, to tune test expectations ;/ > -- > Simon South > si...@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. -- Regards, Bengt Richter
