Comment 41 for bug 675347

Revision history for this message
Launchpad Janitor (janitor) wrote :

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<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.

  [ 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 <email address hidden> Wed, 23 Mar 2011 15:48:14 +0100