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
