Processing control commands:
tags -1 + wontfix
Bug #731060 [src:gcc-defaults] gcc-defaults: Please move symlink of
/usr/include/asm from 'gcc-multilib' to 'gcc' package
Added tag(s) wontfix.
tags -1 - patch
Bug #731060 [src:gcc-defaults] gcc-defaults: Please move symlink of
/usr/include/asm
Control: tags -1 + wontfix
Control: tags -1 - patch
Control: severity -1 wishlist
Am 01.12.2013 15:39, schrieb Hiroyuki Yamamoto:
Source: gcc-defaults
Version: 1.123
Severity: important
Please move symlink of /usr/include/asm
from 'gcc-multilib' to 'gcc' package, because
No, ideally,
Control: tags -1 + moreinfo
Afaics, the situation didn't change. There is nobody committing to work on the
toolchain for these architectures. At least for release architectures the
alternative is to drop the port unless somebody wants to maintain the toolchain
for this port. This is the current
Processing control commands:
tags -1 + moreinfo
Bug #731069 [src:gcc-defaults] gcc-defaults: Please resume considering to
change using unified version of gcc
Added tag(s) moreinfo.
--
731069: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731069
Debian Bug Tracking System
Contact
Hi!
On 12/02/2013 01:14 PM, Matthias Klose wrote:
Afaics, the situation didn't change. There is nobody committing to work on the
toolchain for these architectures. At least for release architectures the
alternative is to drop the port unless somebody wants to maintain the
toolchain
for
Package: gcc-4.7
Version: 4.7.2-5
Severity: wishlist
Tags: patch
Hi,
please add powerpcspe to the list of architectures with --with-long-double-128
in debian/rules2. I have tested this already, and the default gcc-4.6 as well
as the powerpc port do already.
Thanks in advance,
Roland
--
I have no objection to moving to a unified version of gcc on hppa.
gcc-4.8
would be my choice.
On 2-Dec-13, at 7:14 AM, Matthias Klose wrote:
Control: tags -1 + moreinfo
Afaics, the situation didn't change. There is nobody committing to
work on the
toolchain for these architectures. At
Hi,
According the debian bug report [1], it is not possible to use std::future
on armv5 targetting toolchains. This is because libstdc++ will only enable
std::future if ATOMIC_INT_LOCK_FREE 1. There is no LDREX for armv5 and
older, so this definition is set to ATOMIC_INT_LOCK_FREE when
LAST_UPDATED: Fri Nov 29 16:58:54 UTC 2013 (revision 205535)
Target: sparc-linux-gnu
gcc version 4.8.2 (Debian 4.8.2-7)
Native configuration is sparc-unknown-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
LAST_UPDATED: Fri Nov 29 16:58:54 UTC 2013 (revision 205535)
Native configuration is arm-unknown-linux-gnueabi
=== boehm-gc tests ===
Running target unix
=== boehm-gc Summary ===
# of expected passes12
# of unsupported tests 1
LAST_UPDATED: Sun Dec 1 17:13:23 UTC 2013 (revision 205573)
Target: i486-linux-gnu
gcc version 4.9.0 20131201 (experimental) [trunk revision 205573] (Debian
20131201-1)
=== acats tests ===
FAIL: c52102a
FAIL: c52102c
=== acats Summary ===
# of expected
libffi_3.0.13-10_powerpc.changes uploaded successfully to localhost
along with the files:
libffi_3.0.13-10.dsc
libffi_3.0.13-10.debian.tar.gz
libffi-dev_3.0.13-10_powerpc.deb
lib64ffi-dev_3.0.13-10_powerpc.deb
libffi6_3.0.13-10_powerpc.deb
lib64ffi6_3.0.13-10_powerpc.deb
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 02 Dec 2013 19:06:46 +0100
Source: libffi
Binary: libffi-dev lib32ffi-dev lib64ffi-dev libn32ffi-dev libffi6 lib32ffi6
lib64ffi6 libn32ffi6 libffi6-dbg libffi6-udeb
Architecture: source powerpc
Version: 3.0.13-10
Hi,
I don't know whether it is appropriate that I remark,
I have no objection to moving to gcc-4.8 on ppc64, too.
Matthias Klose wrote:
Control: tags -1 + moreinfo
Afaics, the situation didn't change. There is nobody committing to work on the
toolchain for these architectures. At least
On Mon, 2 Dec 2013, Riku Voipio wrote:
Hi,
According the debian bug report [1], it is not possible to use std::future
on armv5 targetting toolchains. This is because libstdc++ will only enable
std::future if ATOMIC_INT_LOCK_FREE 1. There is no LDREX for armv5 and
older, so this
15 matches
Mail list logo
