Contents
glibc headers in a multiarch environment
Issue
Resolving conflicts between libc0.1-dev, libc0.3-dev, libc6-dev, and libc6.1-dev binary packages from different Debian architectures installed on the same MA-enabled system. For instance, allowing binary packages libc6-dev:amd64 and libc0.3-dev:hurd-i386 to be installed together on amd64, or on hurd-i386, or even on another Debian architecture...
Solution
- [X] DONE
Using glibc-2.21 source package from experimental, write a patch to move all headers in libc<soversion>-dev from /usr/include to /usr/include/$(DEB_HOST_MULTIARCH).
Leave /usr/include symlinks be in libc<soversion>-dev-<multilib_arch> packages, as we do not need them in MA anyway.
- [ ] WIP
- Build patched glibc and install it.
- Rebuild all archive: setup wanna-build, buildd, sbuild...
- [ ] WIP
- For each maybe-failed package, rebuild with unpatched glibc.
- If also maybe-failed, record failure here.
- If maybe-succeeded, patch package to support /usr/include/$(DEB_HOST_MULTIARCH) instead of /usr/include.
Anyhow, patch each package assuming libc<soversion>-dev headers to be found in hardcoded /usr/include.
- [ ] Merge the MA headers patch in glibc.
N.B.: Beware of multilib-related issues, e.g. -m64, -m32, and -mx32 on amd64.
Known Problems
gcc-5 (and other versions) cross compiler builds search for includes in /usr/$(DEB_HOST_GNU_TYPE)/include, /usr/include and for asm headers /usr/include/$(DEB_HOST_MULTIARCH)/asm, but they do not search /usr/include/$(DEB_HOST_MULTIARCH) in general. TODO: Diagnose and file bug and patch (debian/rules2 sets up a sys-include folder which can be extended).
gcc "fixes" includes during build. In that process, it also replaces <limits.h>. During build, it determines whether to include the original <limits.h> by testing whether it exists in the system header dir. Unless the point above this one changes the location of the system header directory, this results in a broken replacement. As a workaround, one can set LIMITS_H_TEST=: in src/gcc/Makefile.in.
The initial patch completely breaks multilib. In a multilib setting, /usr/include/$(DEB_HOST_MULTIARCH) is not searched at all, so all the headers that are moved there are essentially gone when building with multilib. Some headers are already in multiarch locations and for those headers the libc6-dev-$multilib packages already contain symlinks. This symlink farm needs to be extended to cover all moved headers.
pythonX.Y hardcodes /usr/include/netinet/in.h.
glibc patch
People involved
?HelmutGrohne