This bug was fixed in the package gcc-4.5 - 4.5.2-7ubuntu1 --------------- gcc-4.5 (4.5.2-7ubuntu1) natty; urgency=low * Merge with Debian. gcc-4.5 (4.5.2-7) unstable; urgency=low * Update to SVN 20110323 (r171351) from the gcc-4_5-branch. - Fix PR c++/47125, PR fortran/47348, PR libstdc++/48114, PR libfortran/48066, PR target/48171, PR target/47862. PR preprocessor/48192. [ Steve Langasek ] * Make dpkg-dev versioned build-dependency conditional on whether we want to build for multiarch. * Add a new patch, gcc-multiarch+biarch.diff, used only when building for multiarch to set our multilib paths to the correct relative directories. * debian/rules.defs: support turning on multiarch build by architecture; but don't enable this yet, we still need to wait for dpkg-dev. * When DEB_HOST_MULTIARCH is available (i.e., with the next dpkg upload), use it as our multiarch path. * debian/rules.d/binary-java.mk: jvm-exports path is /usr/lib/jvm-exports, not $(libdir)/jvm-exports. * OTOH, libgcj_bc *is* in $(libdir). * the spu build is not a multiarch build; look in the correct non-multiarch directory. * 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 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. [ Loic 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. * Add patch armhf-triplet-backport, support for arm-linux-*eabi* backported from a patch sent on the upstream mailing-list. [ Matthias Klose ] * Fix PR target/48226, Allow Iterator::vector vector on powerpc with VSX, taken from the trunk. * Fix PR preprocessor/48192, make conditional macros not defined for #ifdef, proposed patch. * Build the gold LTO plugin for ppc64 (Hiroyuki Yamamoto). Closes: #618864. * Fix issue with volatile bitfields, default to -fstrict-volatile-bitfields again on armel for Linaro builds. LP: #675347. -- Matthias Klose