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