Hi Colin, > Hmm. So I just dug out the VM that I'd been using to look into this, > brought it up to date, and found that man works fine for me: this is a > sid x32 chroot on a stretch amd64 base system running a 4.9.0-4-amd64 > kernel. So that means I'm sort of stalled on this for now: perhaps
Hmm. I’m using the sid kernel; unclear if that makes a difference, but new kernels have been known to either fix or introduce problems specific to x32, e.g. audio was totally broken for some time. > In the meantime, you can add MAN_DISABLE_SECCOMP=1 to your environment > as a workaround (but please remember to remove that again once I release > 2.8.3 so that we can tell whether it fixes the problems). Thanks, that indeed helps (and thus confirms that this was the particular problem). > it's worth seeing if any of the other fixes in 2.8.3 happen to cover > this? The strace shows nroff being killed by SIGSYS immediately after > the execve, with no indication of what system call it attempted that > failed, but if it's the clock_gettime thing I speculated on earlier > then > https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=770cd67aaf711b2cded9cbc2f9e503ca0f5e73ba > should fix it. Interesting. People not only mix and match for performance reasons but also due to bugs, etc. and because x32 isn’t a full architecture in the first place anyway. Hmm, let me see… tglase@tglase:~ $ file /usr/bin/nroff /usr/bin/nroff: POSIX shell script, ASCII text executable Ah-hah! My /bin/sh is indeed klibc-built, and klibc pretends x32 is amd64 because it lacks x32 support (despite klibc’s author being the person behind x32…). If I temporarily symlink /bin/sh to bash, man works (I removed the export from above *and* tested that it indeed fails, just to make sure), so, yes, this would do the trick. Thanks! (I’ll take the reply to the other issue separately.) bye, //mirabilos -- 15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
