boost-build can't handle being cross compiled, as it expects to be able to execute intermediately built binaries.
Steps to Reproduce:
1. Builder a cross-compile toolchain for a foreign arch (say, arm) (including xmerge)
2. xmerge boost-build
# xmerge boost-build
Calculating dependencies... done!
>>> Verifying ebuild Manifests...
>>> Emerging (1 of 1) dev-util/boost-build-1.34.1 to /mnt/arm_root/
* boost_1_34_1.tar.bz2 RMD160 ;-) ... [ ok ]
* boost_1_34_1.tar.bz2 SHA1 ;-) ... [ ok ]
* boost_1_34_1.tar.bz2 SHA256 ;-) ... [ ok ]
* boost_1_34_1.tar.bz2 size ;-) ... [ ok ]
* checking ebuild checksums ;-) ... [ ok ]
* checking auxfile checksums ;-) ... [ ok ]
* checking miscfile checksums ;-) ... [ ok ]
* checking boost_1_34_1.tar.bz2 ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking boost_1_34_1.tar.bz2 to /var/tmp/portage/dev-util/boost-build-1.34.1/work
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/dev-util/boost-build-1.34.1/work/boost_1_34_1/tools ...
### Using 'cc' toolset.
rm -rf bootstrap
arm-unknown-linux-gnu-gcc -o bootstrap/jam0 -mcpu=arm9 -Os -pipe -fno-strict-aliasing command.c compile.c debug.c execunix.c expand.c fileunix.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execnt.c filent.c
./bootstrap/jam0 -f build.jam --toolset=cc --toolset-root= clean
./build.sh: line 15: ./bootstrap/jam0: cannot execute binary file
* ERROR: dev-util/boost-build-1.34.1 failed.
And why do you want to cross-compile boost-build?
For boost you'll have to use the hosts boost-build to build boost for the target.
This bug should be closed as INVALID. BJam is a host tool and should be built as such. In the future: remember to use your site-config.jam or user-config.jam to set up your cross compiler as per the Boost.Build documentation.
This bug has not been touched in almost three years and 1.34 is not even in the tree any more... maybe it can be closed?
With current state of portage dependency algorithms it's nearly impossible to handle this in a sane way.
Suggested workaround: emerge -1 boost-build
Then you can safely start cross-compilation