On Mon, Dec 02, 2013 at 01:14:17PM +0100, 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
On Sun, 2013-12-01 at 18:24 +0200, Eugene V. Lyubimkin wrote:
2013-11-16 15:05, Eugene V. Lyubimkin:
For some reason, on armel architecture exclusively [1], g++ has problems
compiling seemingly any program which uses std::future [2].
std::future is actually defined in libstdc++'s headers
On 3 December 2013 01:19, Nicolas Pitre nicolas.pi...@linaro.org wrote:
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
According to this bugzilla entry, the issue is how
ATOMIC_INT_LOCK_FREE is computed, which is not the same as the for
the __atomic_always_lock_free builtin (I checked on armv5 the builtin
is true for int whereas the macro value is 1). There is a proposed
patch, but it still has some issues...
LAST_UPDATED: Fri Nov 29 16:58:54 UTC 2013 (revision 205535)
Target: mipsel-linux-gnu
gcc version 4.8.2 (Debian 4.8.2-7)
Native configuration is mipsel-unknown-linux-gnu
=== g++ tests ===
Running target unix
=== g++ Summary for unix ===
# of expected passes
Package: gcc-4.8
Version: 4.8.2-7
Severity: normal
--- Please enter the report below this line. ---
Compiling a 64bit kernel on my 32 bit host results on a kernel that does
not boot and hangs while decompressing. Kernels compiled with gcc-4.7
works perfectly fine.
I've uploaded both kernels
Am 02.12.2013 23:20, schrieb Hiroyuki Yamamoto:
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.
this is not a question about any objections, but about a call to the ppc64
porters if they are able to maintain such a port in
Hi,
(2013/12/04 9:52), Matthias Klose wrote:
Am 02.12.2013 23:20, schrieb Hiroyuki Yamamoto:
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.
this is not a question about any objections, but about a call to the ppc64
porters
gcc-4.8_4.8.2-8_amd64.changes uploaded successfully to localhost
along with the files:
gcc-4.8_4.8.2-8.dsc
gcc-4.8_4.8.2-8.diff.gz
gcc-4.8-source_4.8.2-8_all.deb
gcj-4.8-jre-lib_4.8.2-8_all.deb
gcj-4.8-source_4.8.2-8_all.deb
libgcj-doc_4.8.2-8_all.deb
(debugging files)
Changes:
gcc-4.8 (4.8.2-8) unstable; urgency=medium
.
* Update to SVN 20131203 (r205647) from the gcc-4_8-branch.
* Fix PR libgcc/57363, taken from the trunk.
Checksums-Sha1:
4dac999dea8cee1d0e83234149138485ffd99fc0 11218 gcc-4.8_4.8.2-8.dsc
10 matches
Mail list logo
