Bug#766708: breaks multiarch cross building

[Helmut Grohne <helmut@subdivi.de>]

Control: reassign -1 tech-ctte

Dear technical committee,

I ask you to overrule the gcc maintainer and rule that the following
hunks to the gcc-4.9 package must be reverted:

diff -u gcc-4.9-4.9.1/debian/rules.defs gcc-4.9-4.9.1/debian/rules.defs
--- gcc-4.9-4.9.1/debian/rules.defs
+++ gcc-4.9-4.9.1/debian/rules.defs
@@ -125,6 +125,9 @@
   $(error Invalid architecure.)
 endif

+# Force this, people get confused about the default. See #760770.
+with_deps_on_target_arch_pkgs :=
+
 # including unversiond symlinks for binaries
 #with_unversioned = yes

@@ -1449,9 +1447,7 @@
 #ifeq ($(trunk_build),yes)
 #  no_biarch_libs := yes
 #endif
-ifdef DEB_CROSS_NO_BIARCH
-  no_biarch_libs := yes
-endif
+no_biarch_libs :=

 ifeq ($(no_biarch_libs),yes)
   with_lib64gcc                := no

Rationale:

Prior to these changes it was possible to build a gcc cross compiler
with different properties from the default build by setting
with_deps_on_target_arch_pkgs=yes and DEB_CROSS_NO_BIARCH=yes. This
functionality is extensively tested[1] and in particular provides the
only known working way to bootstrap new architectures. I am
maintaining[2] this functionality by submitting patches to the gcc
package.

I acknowledge that the gcc maintainer claims that this method is broken.
His reasons seem to resonate mostly with in-archive cross toolchains and
not with throw-away cross toolchains used for bootstrapping. I
acknowledge that supporting this alternative method of building cross
compilers puts additional work on the gcc maintainer, but this work is
mostly limited to merging patches.

Why is with_deps_on_target_arch_pkgs needed?

Without this flag, gcc emits dependencies on libc*-$arch-cross. In order
to satisfy these dependencies binary packages from glibc have to be
repacked and renamed. When using the resulting cross toolchain to build
further Debian packages there are two choices, both of which are bad:
 * Newly cross built packages also depend on libc6-$arch-cross. This
   will make them different from natively built packages and in
   particular makes debootstrap fail.
 * Newly cross built packages keep their dependency on libc6. This will
   make them uninstallable in the build chroot, because there is no
   foreign arch libc package that can be co-installed with the
   aforementioned libc*-$arch-cross.
Either option makes the bootstrap of a new architecture fail.

Why is DEB_CROSS_NO_BIARCH needed?

There currently is a bug in rebootstrap that makes building multilib
enabled cross-toolchains fail. Thus far I failed to figure out the
reasons for this failure (beyond knowing that gcc looks for crti.o in
the wrong directory). So in the spirit of having something working
rather than nothing, this fiddle is needed to bootstrap multilib-enabled
architectures now. I intend to eliminate the need DEB_CROSS_NO_BIARCH.

Timing

I believe that it is very bad timing to disable a well tested
functionality given the imminent freeze.  This is also a reason for me
to believe that reverting the aforementioned hunks poses little
additional work on the gcc maintainer: There won't be much changes to
put into jessie.  The subject of this bug shall be limited to jessie,
because there is much time to resolve the dispute for jessie+1 in a
reasonable manner and there is reason to believe that the gcc maintainer
will supports finding a resolution.

Helmut

[1] https://wiki.debian.org/HelmutGrohne/rebootstrap
[2] #716795 #742358 #742539 #743718 #743764 #744265 #744782 #745267
    #747526 #751001 #751919 #758408 #743342