$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] Problem cross-compiling boost.context for Raspberry Pi (2)
From: Biddiscombe, John A. (biddisco_at_[hidden])
Date: 2015-06-16 03:39:07
Oliver, Vladimir
Thank you both for the fast replies. The build appears to be fixed now. I wish I has posted my question last night instead of staying up till 1am trying to work out what was wrong!
For future googlers and readers of the list, I amended my user-config.jam to read as follows, (it appears that <compile-flags> is incorrect and I should have used <compileflags>, so now I can omit them from the b2 options and they are picked up correctly).
contents of ~/user-config.jam
using gcc : pi :
/home/biddisco/pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ :
<compileflags>"-D__arm__ -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard"
;
Then after bootstrap.sh
./b2 -d+2 toolset=gcc-pi architecture=arm address-model=32 abi=aapcs binary-format=elf --debug-configuration --without-python -s NO_BZIP2=1 --layout=versioned threading=multi link=shared variant=release --prefix=/home/biddisco/apps/boost-1.58.0 -j8
and I have a complete set of libraries including context and coroutine.
>
you specify cxxflags, but you don't apear to specify linkflags. That's quite dangerous - the three -m options above affect multilib selection, and if multilib differs between compilation and linking, it's bad.
<
Quite right. the forcing of libpthread.a I mentioned was for a CMake try_compile step which resulted in fail as the link step was incorrect. Looking in the compiler toolchain, I see that there are the basic libs required in there, so I shall amend my procedure accordingly and make sure that CMake looks in the correct place.
Many thanks again.
JB