/usr/share/doc/gcc-4.5/README.Debian.gz contains arch-specific patch information, makes it not multiarch-safe

Two options that I can see:

 - add arch-specific sections to README.Debian.gz with an appropriate callout
 - generate README.Debian.gz as an arch-neutral file, and add extra per-architecture files as README.Debian.$arch.gz

Neither is particularly straightforward given gcc's dynamic population of $(debian_patches).

Well, the other option is to flatten debian_patches so that architecture-specific patches are applied to all builds, but this obviously carries some risk and would need to be evaluated patch-by-patch.

Review of these patches:

hurd-pthread - all code is conditional on HURD, __GNU__, GC_GNU_THREADS defines. I believe this is safe to enable cross-architecture.
alpha-ieee, alpha-ieee-doc - patching arch-specific code / documentation, safe to enable cross-architecture.
mudflap-nocheck - alpha-specific workaround, not appropriate to enable everywhere. Should maybe be dropped? (dates back to 2009-03 or earlier, no idea if anyone's tested without on alpha lately or if anyone even cares now)
libjava-armel-unwind - arm-specific workaround for a bug somewhere else (possibly in libjava/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkToolkit.c, according to the referenced thread). Should not be applied cross-platform, maybe should be dropped instead (after checking that the underlying bug is fixed)
powerpc_remove_many - conditional on __SPE__, I believe this is safe.
ibm-branch - big scary patch touching common files, not safe to include on !powerpc64 :(
kbsd-gnu.diff - clean conditions, could be applied to all archs
hurd-changes.diff - touches hurd-specific code, safe to enable
libstdc++-no-testsuite - disabling testsuite, should not be enabled cross-architecture, don't know if it's still needed but it was added fairly recently (maverick)
libmudflap-no-testsuite - idem
gcc-ppc64-O3 - looks arch-specific

So there is some room for improvement in terms of patches being arch-specific when they shouldn't need to be, but not enough to get us all the way there for multiarch. I think the better solution is simply to push the debian_patches list to an arch-specific file, and put a footer at the bottom of README.Debian.gz that explains where to look.

I would also prefer if we could avoid architecture specific patches; it makes it really painful to ensure patches are compatible with each other, and it's hard to test all relevant combinations.

At the same time, some patches are fairly large like the Linaro diff, so I can see this need staying for a while.

Perhaps a simpler option altogether: could we not simply point people at the source to check out which patches are applied?

(BTW I just added one arch specific patch recently to add support for the armhf triplet; it's entirely not arch specific and could be applied unconditionally; I chose not to as other patches were applied based on architecture and I didn't want to take the slighest risk in regressing other builds, but I'm happy if it gets applied unconditionally after this discussion.)

On Fri, Mar 18, 2011 at 11:55:36PM -0000, Loïc Minier wrote:

> Perhaps a simpler option altogether: could we not simply point people at
> the source to check out which patches are applied?

Possible, but I think that's up to Matthias since whatever we do here we
want to be applicable in Debian and Ubuntu.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world

This bug was fixed in the package gcc-4.5 - 4.5.2-6ubuntu5

---------------
gcc-4.5 (4.5.2-6ubuntu5) natty; urgency=low

  [ Loïc Minier ]
  * Rework config/vxworks-dummy.h installation snippet to test
    DEB_TARGET_GNU_CPU against patterns close to the upstream ones (arm% mips%
    sh% sparc%) as to also install this header on other ports targetting the
    relevant upstream CPUs such as armhf. Add a comment pointing at the
    upstream bug.
  * Update __aeabi symbol handling to test whether DEB_TARGET_GNU_TYPE matches
    arm-linux-gnueabi% instead of testing whether DEB_TARGET_ARCH equals
    armel. Add a comment pointing at the Debian bug and indicating that this
    is only useful for older dpkg-dev versions.
  * debian/rules.def: fix "armel" entry to "arm" in list of
    DEB_TARGET_ARCH_CPUs for Debian experimental GCC 4.5/4.6 libraries.
  * debian/rules2: drop commented out GCC #42509 workaround as this was fixed
    upstream in 4.4+.
  * Change bogus DEB_TARGET_GNU_CPU test on armel and armhf to just test for
    arm as ths is what the Debian arm, armel and armhf port use.
  * Rework snippet setting armv7 on Debian armhf / Ubuntu to avoid
    duplication, as a comment called out for.
  * Use "arm" instead of armel/armhf in DEB_TARGET_GNU_CPU test when deciding
    whether to enable profiledbootstrap.
  * Set DEJAGNU_TIMEOUT=600 on Ubuntu armhf as well.
  * Fix a couple more uses of armel or armhf against DEB_TARGET_GNU_CPU.
  * Patched a couple of comments mentioning armel to also mention armhf.
  * Rename Vcs-* fields to XS-Debian-Vcs-*.
  * Add patch armhf-triplet-backport, support for arm-linux-*eabi* backported
    from a patch sent on the upstream mailing-list.

  [ Steve Langasek ]
  * debian/rules2: pass --libdir also for stageX builds, needed in order to
    successfully build for multiarch.
  * debian/rules2: $(usr_lib) for a cross-build should not include the
    multiarch dir as part of the path.
  * debian/patches/gcc-multiarch+biarch.diff: restore the original intent of
    the patch, namely, that the multilib dir for the default variant is
    always equal to libdir (the multiarch dir), and we walk up the tree
    to find lib<qual> for the secondary variant.
  * debian/patches/gcc-multiarch+biarch32.diff: apply the same multilib
    directory rewriting for biarch paths with multiarch as we do without;
    still needed in the near term.
  * Put our list of patches in README.Debian.$(DEB_TARGET_ARCH) instead of
    in README.Debian, so that the individual files are architecture-neutral
    and play nicely with multiarch. LP: #737846.
  * Add a comment at the bottom of README.Debian with a pointer to the new
    file listing the patches.
 -- Steve Langasek <email address hidden> Sun, 20 Mar 2011 23:39:24 -0700