Front page | perl.perl5.porters |
Postings from July 2012
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 Clark
Thread Previous
|
Thread Next