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 Kernel
Packages, which is subscribed to linux-ti-omap4 in Ubuntu.
https://bugs.launchpad.net/bugs/750585
Title:
[FFe] support for making linux-libc-dev coinstallable under multiarch
Status in armel-cross-toolchain-base package in Ubuntu:
Fix Released
Status in bash-completion package in Ubuntu:
Fix Released
Status in eglibc package in Ubuntu:
Fix Released
Status in gcc-defaults package in Ubuntu:
Fix Released
Status in klibc package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in linux-ti-omap4 package in Ubuntu:
Invalid
Status in newlib package in Ubuntu:
Fix Released
Status in armel-cross-toolchain-base source package in Natty:
Fix Released
Status in bash-completion source package in Natty:
Won't Fix
Status in eglibc source package in Natty:
Fix Released
Status in gcc-defaults source package in Natty:
Fix Released
Status in klibc source package in Natty:
Fix Released
Status in linux source package in Natty:
Fix Released
Status in linux-ti-omap4 source package in Natty:
Fix Released
Status in newlib source package in Natty:
Fix Released
Status in armel-cross-toolchain-base source package in Oneiric:
Invalid
Status in bash-completion source package in Oneiric:
Won't Fix
Status in eglibc source package in Oneiric:
Fix Released
Status in gcc-defaults source package in Oneiric:
Fix Released
Status in klibc source package in Oneiric:
Fix Released
Status in linux source package in Oneiric:
Fix Released
Status in linux-ti-omap4 source package in Oneiric:
Fix Released
Status in newlib source package in Oneiric:
Fix Released
Bug description:
FFe justification: now that multiarch support for runtime libraries in
the base system is available in the archive, the next step in this
process is multiarch coinstallability of -dev packages. Although most
of the remaining work on multiarch -dev can and will take place in ppa
for natty given where we are in the release cycle, any -dev package
tree has at its root linux-libc-dev which is built from the 'linux'
source package - the package which is updated more frequently than any
other by SRU. Rather than trying to keep up with SRUs, or
artificially inflating the version of a linux-libc-dev-only package
build in ppa, it would be welcome if a multiarch-ready linux-libc-dev
could be included in the archive for natty.
Risks: anything that looks directly in /usr/include/asm for headers
will have problems with this change; anything that uses the system
include path from the compiler will not. My best efforts at examining
the archive for this issue (see below for details) have turned up only
four packages in main and universe that are affected: three C library
implementations, and bash-completion. Updating these packages in
concert is manageable (patch for eglibc is ready, patches for the
others are in preparation), but there's always some risk that the text
search on package sources has missed something, and there wouldn't be
room for another full archive rebuild before release to catch other
breakage.
Details:
In order to have coinstallable multiarch -dev packages of any sort,
linux-libc-dev first needs to be coinstallable since libc-dev depends on it.
This seems to be straightforward to achieve; only the asm directory needs to be
moved to the multiarch directory path, all the other header files appear to be
(sensibly) architecture-neutral and can be shared between architectures.
The compiler will find /usr/include/<triplet>/asm for the
corresponding architecture with no problems; I've done a number of
test builds that work just fine this way. The only trouble is with
software that walks the filesystem looking for asm/<foo>.h includes
instead of trusting the compiler to resolve them. It's unlikely that
software should need to do this since the asm headers should as a rule
not be directly included from userspace anyway, but the chances are
not zero. I didn't expect nearly as many packages to break as did by
the move to /usr/lib/<triplet>, either, so it seems my faith in the
sanity of upstream build systems is generally misplaced. And I don't
think we have time to discover any resulting issues with another
archive test rebuild and fix the resulting packages before the natty
release.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/armel-cross-toolchain-base/+bug/750585/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
