Re: [boost] Problem cross-compiling boost.context for Raspberry Pi (2)

Subject: Re: [boost] Problem cross-compiling boost.context for Raspberry Pi (2)
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-06-16 02:49:07

On 6/16/2015 9:22 AM, Biddiscombe, John A. wrote:

> and the build appears sensible when I use
> ./b2  cxxflags="-D__arm__  -std=c++11 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard"  --layout=versioned threading=multi link=shared variant=release -j8

Hi John,

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.

> using gcc : : /home/biddisco/pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ : <compile-flags>-D__arm__ -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard ;

The same problem here. Also, the value of "<compile-flags>" option probably should be quoted? Is this 
user-config.jam actually read - I would expect a syntax error here. You can use --debug-configuration
to make sure it's read, and please quote the value in any case.

> (Note : With another project which depends on libpthread, I had to copy libpthread from the pi to the host and force the linker to use the pthread lib from the pi and not the host one, does bjam do something internally which might require a trick like this? - note2 - the binaries generated via this process run without error)

Copying libpthread would suggest the sysroot you have on host is different from sysroot on target - and if 
that's that case, everything will likely explode sooner or later. It would be good to veryfy that
your host toolchain matches exactly what's on target.

With the above issues fixed, I would expect this alternative in libs/context/build/Jamfile.v2 to be taken:

    alias asm_context_sources
    : asm/make_arm_aapcs_elf_gas.S
      asm/jump_arm_aapcs_elf_gas.S
    : <abi>aapcs
      <address-model>32
      <architecture>arm
      <binary-format>elf
      <toolset>gcc
    ;

Could you try forcing it, by:

        b2 abi=aapcs binary-format=elf address-model=32 architecture=arm toolset=gcc <further-options>

If this works, it would mean some of these options end up defaulted incorrectly, with abi and binary-format
particularly suspect. What's your host system, not OSX per chance?

Thanks,
Volodya