According to http://www.boost.org/doc/libs/1_63_0/libs/context/doc/html/context/architectures.html bost context & coroutines are supported by all but sparc architectures but yocto enables it only for x86. The following snippet enables context & coroutines for arm [snippet] BJAM_OPTS_append_arm += " abi=aapcs binary-format=elf address-model=32 architecture=arm " BJAM_OPTS_append_arm-64 += " abi=aapcs binary-format=elf address-model=64 architecture=arm " BOOST_LIBS_append_arm = " context coroutine " BOOST_LIBS_append_arm-64 = " context coroutine " [/snippet] It will be great if you'll add it by default.
A similar patch was ran on the autobuilder and it failed. https://autobuilder.yocto.io/builders/nightly-arm-lsb/builds/218/steps/BuildImages/logs/stdio has the full log but it starts at: | In file included from ./boost/context/execution_context.hpp:17:0, | from libs/context/src/execution_context.cpp:7: | ./boost/context/execution_context_v2.hpp: In member function 'boost::context::execution_context<Args>::ret_tpl_t boost::context::execution_context<Args>::operator()(Args ...)': | ./boost/context/execution_context_v2.hpp:298:31: error: 'exception_ptr' is not a member of 'std' | auto p = std::make_tuple( std::exception_ptr{}, std::move( data) ); | ^~~ My C++-fu is pretty bad, but it looks like it's getting confused about what C++ standard it's meant to be using?
It depends how similar it is :). Maybe it add more things. Where is that patch? Can I see it?
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/boost&id=791f696bddb85d12e32073f31995d8c0a2312386
It looks the same :O ... The only difference I see is the missing space at the end of BJAM_OPTS_append_xxxx... I test it on raspberry pi and it worked ok. I try to reproduce it on the same machine.
Can you try it on qemuarm?
Yep, this is what I'm going to do. I hope it doesn't somehow disable C++11, because std::exception_ptr needs it.
So there is this amazing line in the boost.inc where we tell boost that gcc is 4.2.1 because it appears telling it the compiler flags again is the only way to actually get them respected. (deleting that line makes the build fail) I wonder if the 4.2.1 is breaking something and we should replace it with the version of the compiler we're actually using.
Well gcc 4.2.1 for sure didn't had any C++11 support. But in this case why it's working for rapsberrypi3 and for x86 ?
I'm experiencing the same problem when trying to build for qemuarm ... From the build log it seems it doesn't set the C++ standard to compiler flags ... I'll see what I can do
Eureka! The following patch worked for me. I tested on older custom yocto version because on master I don't know how to prevent it to reset my local changes :) diff --git a/meta/recipes-support/boost/boost.inc b/meta/recipes-support/boost/boost.inc index 4ff70e399b..ccdeea2b96 100644 --- a/meta/recipes-support/boost/boost.inc +++ b/meta/recipes-support/boost/boost.inc @@ -28,10 +28,16 @@ BOOST_LIBS = "\ wave \ " -# only supported by x86 and powerpc +# only supported by x86, arm and powerpc BOOST_LIBS_append_x86 = " context coroutine" BOOST_LIBS_append_x86-64 = " context coroutine" BOOST_LIBS_append_powerpc = " context coroutine" +BOOST_LIBS_append_arm = " context coroutine " +BOOST_LIBS_append_arm-64 = " context coroutine " + +BJAM_OPTS_append_arm += " abi=aapcs binary-format=elf address-model=32 architecture=arm " +BJAM_OPTS_append_arm-64 += " abi=aapcs binary-format=elf address-model=64 architecture=arm " + # need consistent settings for native builds (x86 override not applied for native) BOOST_LIBS_remove_class-native = " context coroutine" # does not compile @@ -176,7 +182,7 @@ do_configure() { # D2194:Fixing the failure of "error: duplicate initialization of gcc with the following parameters" during compilation. rm -f ${WORKDIR}/user-config.jam - echo 'using gcc : 4.3.1 : ${CXX} : <cflags>"${CFLAGS}" <cxxflags>"${CXXFLAGS}" <linkflags>"${LDFLAGS}" ;' >> ${WORKDIR}/user-config.jam + echo 'using gcc : : ${CXX} : <cflags>"${CFLAGS}" <cxxflags>"${CXXFLAGS}" <linkflags>"${LDFLAGS}" ;' >> ${WORKDIR}/user-config.jam # If we want Python then we need to tell Boost *exactly* where to find it if ${@bb.utils.contains('BOOST_LIBS', 'python', 'true', 'false', d)}; then
If you can tell me how to prevent yocto to reset my local changes I'll test it on master too :)
Aha, simply removing the version forces boost to look for itself? I predict that the boost build changes massively with that change. Last time I tried this it suddenly detected more libraries it should be linking to, and enabled more bits.
We also need to do something about the name of coroutine library... Now boost wants us to enable coroutine2 (not coroutine) but it will still name the lib libcoroutines.a/so... Sadly simply adding coroutine2 breaks the build and my yocto knowledges are way too low to be able to do this change :)
The first fix proposed in this thread is enough with the current boost version. I submitted a patch to the list but have not yet received any answer.
Alban, Thanks for sending the patch. I've pinged the thread on the list and assigned this defect to you. Hopefully this gets wrapped up early this week.
The commit is in master-next so as long as testing goes well, it'll get merged to master: 9a8ffdafa1 boost: Fix build and enable context and coroutines on aarch64 Once that happens, please add the commit id here and close the defect as fixed.
http://cgit.openembedded.org/openembedded-core/commit/?id=5140e0a64aac8c621fe0d839dea41b7b43a96b4d