On Thu, Jul 26, 2012 at 09:59:49AM -0700, Father Chrysostomos via RT wrote: > On Thu Jul 26 09:19:42 2012, nicholas wrote: > > The sparc linux build is still ongoing... > > (I think this is a 32 build on a sparc64 system. The machine is slow, > > and I'm > > not going to interrupt it to find out out for sure) However, the 4 core MIPs box is faster. And on it, $ ./perl -I../lib op/syscall-113980.t 1..1 not ok 1 - syscall retval is not truncated # Failed test 1 - syscall retval is not truncated at op/syscall-113980.t line 26 # got "-1" # expected "2147434496" > > I've not yet tried coaxing a build with -m32 on x86_64 ... -Accflags=-m32 -Aldflags=-m32 -Alddlflags=-m32\ -shared [and I don't know why I need to add -shared - is the hints file buggy?] $ ./perl -I../lib op/syscall-113980.t 1..1 not ok 1 - syscall retval is not truncated # Failed test 1 - syscall retval is not truncated at op/syscall-113980.t line 26 # got "-1" # expected "4160614400" (output of ./perl -pe0 /proc/self/maps >maps attached) > Thank you. That means the skip is not being triggered. Do you know how > to test that this is a 64-bit linux system? Or is this bug something we > just can't reliably test? No, I don't for sure. I think if one is sure it's Linux, run uname -m eg $ uname -m x86_64 $ uname -m mips64 $ uname -m sparc64 vs $ uname -m i686 $ uname -m armv6l I think all the 64 bit architectures happen to match /64$/ However, I suspect that syscall numbers vary with architecture, and arguments might too, so it's not going to be safe to use a hardcoded magic number even on systems which seem to be 64 bits - really, check if it's exactly x86_64. This also assumes that syscall numbers do not change on Linux. I guess that they can't now, given that 3.x.y is really just 2.6.z, but I presume that they can be deprecated and eventually dropped. But as the above demonstrates, it would need to be a 64 bit process on a 64 bit OS. I think the latter is fairly easy - $Config{ptrsize}. > Obviously calling stime is no good, even if it only works under root. > Running tests under root should not set the system time. :-) For starters, I think skip it if running as root. But yes, also skip unless it's linux, skip unless it's x86_64, and skip unless it's a 64 bit build. But I'm not confident how safe or reliable this sort of thing is ever going to be. Nicholas ClarkThread Previous | Thread Next