just saw Steve's earlier comment, apparently the logic to pick the right unistd_32.h or unistd_64.h was added after that, so this is Fix Released, not Invalid.
There's now asm/unistd_x32.h as well. AFAICT from poking around in the kernel source, uname -m should return x86_64 when called from a x86_x32 uname binary. I don't see anything mucking with utsname()->machine, outside of what I think is just the ia32 handling, not used for x86_x32 userspace (since they still run in long mode, with 64 bit registers. They just choose not to use addresses that don't fit in 32bits.) So x86_x32 userspace won't ever get their own unistd.h processed, but it's minimally different from unistd_64.h, and has to be that way for the kernel support to be as minimally invasive as it is. The extra names that unistd_x32.h has that unistd_64.h doesn't is probably not relevant unless you're trying to debug the glibc wrappers around the calls that need help, I hope. You *could* use cpp to get the right unistd.h, but you couldn't just cpp /usr/include/unistd.h, because that would substitute the __NR_callname macros that the script is looking for. ** Changed in: bash-completion (Ubuntu) Status: Invalid => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/750585 Title: [FFe] support for making linux-libc-dev coinstallable under multiarch To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/armel-cross-toolchain-base/+bug/750585/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs