[Pkg-ime-devel] Bug#753079: c++11 mode in GCC is still marked as experimental (although armel needs work)

[Guo Yixuan]

Control: forwarded 754199
https://code.google.com/p/rimeime/issues/detail?id=632
Control: tag 754199 + upstream

Hello,

On Sat, Jul 12, 2014 at 11:10 AM, Osamu Aoki <osamu at debian.org> wrote:
>
> Hi
>
> On Sat, Jul 12, 2014 at 02:00:35PM +0200, Matthias Klose wrote:
> > I would rather drop any package which does use c++11 features without
any
> > reflection.
>
> I now understand the problem.  Thanks.
>
> On Sat, Jul 12, 2014 at 01:10:52PM +0200, Julien Cristau wrote:
> > No, just because some random c++11 thing doesn't work on armel doesn't
> > mean we drop the arch.
> >
> > What it means is packages get to work without it until it's fixed.
>
> Yes, I see.  (I was wrong.)
>
> https://bugs.debian.org/727621
> There seems to be some issue related to ATOMIC_type_LOCK_FREE.  (I have
> no clue but it is related to type.)
>
> I also see FEDORA applied attached arm patch changing float to double
> and doing the alignment computing for mapped file.
>
> Is this patch something which work around the issue on armel?

Thank you, however it doesn't seem to be so. The misalignment
is another unrelated problem, which causes ftbfs for src:brise.
(On the develop branch, the misalignment bug is believed to be
fixed for arm, which I'm not able to test. I do have a sparc
machine to test on, where the problem is not fixed.)

> Also, as I see the upstream git repo, just after his release of this
> tar, he is commiting
>      5c274357ceaaff941b91e12d3f2f4714df0ecd16
> to revert CMakeLists.txt of oldscheool branch as:
>
> -if(UNIX)
> -  add_definitions("-std=c++11")
> -endif(UNIX)
>
> Then recent commit has
> + if(NOT BOOST_USE_CXX11)
> +   add_definitions("-DBOOST_NO_CXX11_SCOPED_ENUMS")
> + endif()
>
> Are these kind of updates needed?
>
> Guo Yixuan,
>
> Can you talk to the upstream on this issue and what oldschool devel
> branches mean?
>
> Osamu

I've just reported the current situation to the upstream.[1] The commit
(5c27435) that you mentioned is only in the branch msvc10, apparently
to work around certain limitations for the windows port. I'm asking the
upstream to apply it (or only the std::future part of it) on the develop
branch, as a fix of our current problem.

[1] https://code.google.com/p/rimeime/issues/detail?id=632
(in English and Chinese, and feel free to comment in English)

GUO Yixuan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-ime-devel/attachments/20140712/d7400f8c/attachment.html>