Does libgcc2.c only get built if building gcc-multilib? I thought the libgcc build was happening because we build a static libgcc in DEB_STAGE=stage1 and that that is actually needed? I agree if it's not needed then lets not build it.
I think this works on the buildds because there is a /usr/include/bits/predefs.h installed by some package or other, and if that is present then you see no error, even though a wrong-arch header has been picked up.
Something odd is going on because you end with that file existing, but not owned by dpkg according to dpkg -S /usr/include/bits/predefs.h
libc6-dev-i386 owns the /usr/include/bits dir, and removing it removes the contents.
I defer to experts as to what is the correct fix for all this. As you say the cross-toolchain builds do actually work, but more by luck than actual correctness, so far as I can see.
Now filed upstream as http:// gcc.gnu. org/bugzilla/ show_bug. cgi?id= 55743
Does libgcc2.c only get built if building gcc-multilib? I thought the libgcc build was happening because we build a static libgcc in DEB_STAGE=stage1 and that that is actually needed? I agree if it's not needed then lets not build it.
I think this works on the buildds because there is a /usr/include/ bits/predefs. h installed by some package or other, and if that is present then you see no error, even though a wrong-arch header has been picked up.
Something odd is going on because you end with that file existing, but not owned by dpkg according to dpkg -S /usr/include/ bits/predefs. h
libc6-dev-i386 owns the /usr/include/bits dir, and removing it removes the contents.
I defer to experts as to what is the correct fix for all this. As you say the cross-toolchain builds do actually work, but more by luck than actual correctness, so far as I can see.