Your message dated Sat, 31 Dec 2016 04:18:42 +
with message-id
and subject line Bug#727621: fixed in gcc-6 6.3.0-1
has caused the Debian Bug report #727621,
regarding armel: std::future appears to be broken?
to be marked as done.
This means that you claim that the problem has been dealt with
. Please contact ow...@bugs.debian.org
immediately.)
--
727621: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727621
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: g++-4.8
Version: 4.8.1-10
Severity: normal
Hello, thank you for maintaining
Control: reassign -1 gcc4.9,gcc-6
Control: block 834046 by -1
Suspect this librime FTBFS is led by the old issue of std::future in gcc.
Regards,
Aron
. Please contact ow...@bugs.debian.org
immediately.)
--
727621: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727621
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: g++-4.8
Version: 4.8.1-10
Severity: normal
Hello, thank you for maintaining
Control: reassign -1 gcc4.8,gcc4.9
Hi,
This is still a problem with GCC 4.9. Is there any progress on this? This is
making aegisub FTBFS on armel, blocking the libass transition.
Cheers,
Emilio
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
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... ha
On 3 December 2013 01:19, Nicolas Pitre 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 ATOMIC_INT_LOCK_FREE > 1
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 hea
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 def
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 compilin
Hello,
Answering to myself after digging through libstdc++ includes and
sources:
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 libs
Hi,
2013-10-24 23:51, Bastian Blank:
> On Fri, Oct 25, 2013 at 12:12:59AM +0300, Eugene V. Lyubimkin wrote:
> > 2013-10-24 21:45, Bastian Blank:
> > > Please fix cupt to show the complete command-line. The build-logs are
> > > near to useless.
> > In general, I tend to disagree, for noise-to-sign
On Fri, Oct 25, 2013 at 12:12:59AM +0300, Eugene V. Lyubimkin wrote:
> 2013-10-24 21:45, Bastian Blank:
> > Please fix cupt to show the complete command-line. The build-logs are
> > near to useless.
> In general, I tend to disagree, for noise-to-signal and readability
> ratio.
Log from buildds ar
Hi,
2013-10-24 21:45, Bastian Blank:
> Please fix cupt to show the complete command-line. The build-logs are
> near to useless.
In general, I tend to disagree, for noise-to-signal and readability
ratio.
Now if this particular report is near to useless given the information I
provided, I would b
On Thu, Oct 24, 2013 at 08:03:24PM +0300, Eugene V. Lyubimkin wrote:
> When I tried to compile cupt 2.6.x in unstable/experimental, an armel
> build (out of all) failed. This unfortunately blocks cupt's migration to
> testing.
Please fix cupt to show the complete command-line. The build-logs are
Package: g++-4.8
Version: 4.8.1-10
Severity: normal
Hello, thank you for maintaining GCC.
When I tried to compile cupt 2.6.x in unstable/experimental, an armel
build (out of all) failed. This unfortunately blocks cupt's migration to
testing.
unstable, used g++ 4.8 - [1]
unstable, used g++ 4.6 -
16 matches
Mail list logo
