This bug doesn't affect various amd64, arm or x86 profiles, but it does affect (at least) mipsel multilib o32/n32/n64 with n32 default. Running the ebuild as its written ends in multiple instances of compilation terminated. In file included from glob.c:27:0: jam.h:42:20: fatal error: Python.h: No such file or directory #include <Python.h> ^ If, however, we apply the following patch: --- /usr/portage/dev-util/boost-build/boost-build-1.53.0.ebuild 2013-02-12 15:39:04.000000000 +0000 +++ boost-build-1.53.0.ebuild 2013-12-29 23:12:57.160032157 +0000 @@ -88,7 +88,7 @@ toolset=cc fi - CC=$(tc-getCC) ./build.sh ${toolset} -d+2 $(use_with python python "${EROOT}"/usr) || die "building bjam failed" + CC=$(tc-getCC) ./build.sh ${toolset} -d+2 $(use_with python) || die "building bjam failed" } src_install() { it does build, ie replace $(use_with python python "${EROOT}"/usr) with $(use_with python). I'm sorry I can't give you more, I don't understand boost's internals well enough. Reproducible: Always
Created attachment 366508 [details] build log failure for boots-build-1.53.0 on multilibe mips64el
cc-ing the python team since they might have a clue.
This is still an issue with 1.55.0.
Well, looking at the following lines in build.jam, the proposed patch just disables python-support entirely: [...] # Enable, and configure, Python hooks. with-python = ; python-location = [ MATCH --with-python=(.*) : $(ARGV) ] ; if $(python-location) { with-python = true ; } if $(with-python) { [...] so, questions are: * what do we end up with as ${PYTHON_ABI} ? ... please attach engine/build.jam since we patch that * does the calculated python directory (usually /usr/include/python2.7) exist on that specific arch? Besides, we should finally port the boost-build ebuild to python-single-r1
Actually, improper libdir was a culprit. Fixed now, thanks for the report + 16 May 2014; Sergey Popov <pinkbyte@gentoo.org> boost-build-1.53.0.ebuild, + boost-build-1.54.0.ebuild, boost-build-1.55.0.ebuild: + Respect multilib during building Python-related stuff, bug #496446
*** Bug 505694 has been marked as a duplicate of this bug. ***
(In reply to Sergey Popov from comment #5) > Actually, improper libdir was a culprit. Fixed now, thanks for the report ok, so the glob returned empty and --python-include was not set. good job, thanks.
