I found this out because I had a relatively simple perl script that used to work fine (on both 32 and 64 bit x86 platforms), which was using syscall() to call statfs(). When I deployed this script on an x86_64 SuSE 9.2 box for the first time, it segfaulted right around the time of the syscall(). strace revealed that it wasn't actually calling statfs() at all, but rather "sysinfo()", a completely different system call.

Further digging revealed that on 32-bit ix86 platforms, statfs() is system call number 99. On x86_64, statfs() is 137, and sysinfo() is at 99. So clearly, my x86_64 perl is trying to use 32-bit syscall numbers when it shouldn't be.

On other x86_64 installations with older but working 5.8.x versions of perl, /usr/lib/perl5/.../_h2ph_pre.ph contains (among other things):

unless (defined &__x86_64__) { sub __x86_64__() { 1 } }
[download]

On the machine giving issues, this is replaced by:

unless (defined &__amd64__) { sub __amd64__() { 1 } }
[download]

However, /usr/lib/perl5/.../asm/unistd.ph on both installations contain basically the same code:

 if(defined(&__x86_64__)) {
        require 'asm-x86_64/unistd.ph';
    } else {
        require 'asm-i386/unistd.ph';
    }
[download]

So on the erroneous SuSE 9.2 x86_64 perl5.8.5 setup, since _h2ph_pre.ph defines __amd64__ instead of defining __x86_64__, but asm/unistd.ph is still looking for __x86_64__, the result is that it picks up the asm-i386 version of unistd, containing syscall numbers that are not correct for this architecture.

I'm not really sure at this point in time whether whatever bug this is (probably back at perl compilation time) lies in Perl 5.8.5, or in some particulars of the underlying gcc/glibc setup in SuSE 9.2, or is just a bug in how SuSE built this particular rpm of perl.

I haven't been able to google up any reference to anyone else having the same problem though, and I can't see how that would go unnoticed (am I the only person who uses syscall()? ). I peeked inside a Fedora Core 3 RPM for perl 5.8.5 and it seemed to be showing the exact same problem.

So, has anyone else run into this, and do you know the source of it and/or know why vendors haven't patched themselves out of this problem?