Control: user helm...@debian.org
Control: usertags -1 + rebootstrap

On Sun, Oct 26, 2014 at 02:23:07PM +0100, Matthias Klose wrote:
> The patch fixes building multilib enabled stage1 cross, by doing the call xx
> dance for stage1 as well, as well as generating the debhelper files for 
> multilib
> stage1 packages.

Matthias patch does not work for architectures with optimized libcs
(called "otherarch" in glibc packaging, i.e. i386, mipsel, alpha).

Quoting the commit message of
http://anonscm.debian.org/cgit/users/helmutg/rebootstrap.git/commit/?id=b462ceb
for details:

| attempt at fixing glibc multilib stage1 builds
| 
| Currently for mipsel libc6-dev and libc6-dev-mips64 (stage1) are not
| coinstallable, because they have an undeclared file conflict in
| /usr/include/sys. Since libc6-dev is multiarch, it shouldn't contain
| that directory but use something below /usr/include/triplet.
| 
| The cause is the debhelper tooling affected by the patch below. It is
| run for each $curpass, where in case of mipsel passes include libc,
| mips64 and loongson2f. The last one is interesting, because it is not
| covered by either existing cases. In the non-stage1 variant of this
| code, it is classified as a pass=-otherbuild. Since we don't change
| templates or pass for loongson2f, the snippet overwrites the debhelper
| .install files for libc causing the libc6-dev package to contain the
| headers for loongson2f (in non-multiarch locations). So the non-stage1
| restricts templates to just libc for otherbuild. Since stage1 restricts
| templates to libc-dev, the intersection for stage1 and otherbuild is
| empty.
| 
| Arguably, the loongson2f pass should be skipped in stage1 entirely.
| 
| This bug should break any architecture with optimized libc packages:
|  * mipsel -> loongon2f
|  * i386 -> 686 (breaks in gcc earlier atm)
|  * alpha -> alphaev67 (libc6.1-dev and libc6-dev conflict already)

Helmut


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141216195143.ga15...@alf.mars

Reply via email to