When I try to compile boost with mpi support on OSX, I get the following error: error: Duplicate name of actual target: <pstage/lib>mpi.so error: previous virtual target { ... lots of stuff ... } /Library/Gentoo/usr/share/boost-build-1_42/build/virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@4317 /Library/Gentoo/usr/share/boost-build-1_42/build/virtual-target.jam:135: in object(file-target)@4317.actualize from module object(file-target)@4317 /Library/Gentoo/usr/share/boost-build-1_42/build-system.jam:717: in load from module build-system /Library/Gentoo/usr/share/boost-build-1_42/kernel/modules.jam:283: in import from module modules /Library/Gentoo/usr/share/boost-build-1_42/kernel/bootstrap.jam:142: in boost-build from module /Library/Gentoo/var/tmp/portage/dev-libs/boost-1.42.0-r1/work/boost_1_42_0/boost-build.jam:17: in module scope from module I think it may simply be a problem on the Makefile, I need to take a closer look at it. I am using openmpi, by the way. I couldn't get mpich2 to compile, but openmpi works just fine. I am not sure how to report the stuff that works, but openmpi is keyword masked on OSX as of now, I assume it's safe to flag is at least ~x64-macos... Reproducible: Always
dev-libs/boost-1.42.0-r1 USE="eselect mpi -debug -doc -icu -python -static-libs -test -tools" works fine for me. no error found
Created attachment 277055 [details] The build log of =dev-libs/boost-1.45.0 on x64-macos
Created attachment 277057 [details] environment
on prefixed x64-macos $ USE="python mpi" emerge -av =dev-libs/boost-1.45.0 fails with the same error: /opt/gentoo/usr/share/boost-build-1_45/build/virtual-target.jam:1066: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage/lib>mpi.so error: previous virtual target { ... ( a lot of output ) } The build log and environment is attached. Same error occurs for boost-1.46.1 .
Please report this upstream. See [1]. [1] http://www.boost.org/support/bugs.html
Created attachment 277381 [details, diff] Patch from macports to fix the issue This is a patch for Jamfile.v2 taken from macports to resolve the configuration issue of boost with mpi and python flags turned on simultaneosly
Looks like upstream doesn't know about this patch. I'd rather avoid the risk of breaking other arches and configurations and apply it only if really needed. @prefix: How do you suggest to handle this?
I don't know if the patch only touches Darwin specific parts of the jam-file. If it does, no problems, if it doesn't, I'd conditionalise it for darwin.
I should admit, that USE="tools" breaks anyway on x64-macos with a linking error but that's a subject for a different bug.
Created attachment 277387 [details] The gzip of a build log of =dev-libs/boost-1.45.0 on x64-macos after Jamfile.v2 patch This is a build log after Jamfile.v2 patch USE="-tools" emerge -pqv =dev-libs/boost-1.45.0 [ebuild N ] dev-libs/boost-1.45.0 USE="doc eselect icu mpi python -debug -static-libs -test -tools" boost-1.45 fails with a message: >>> Completed installing boost-1.45.0 into /opt/gentoo/var/tmp/portage/dev-libs/boost-1.45.0/image/opt/gentoo/ * QA Notice: Found .so dynamic libraries on Darwin: * opt/gentoo/usr/lib/python2.7/site-packages/boost_1_45/mpi.so * QA Notice: invalid self-reference install_name mpi.so in /opt/gentoo/usr/lib/python2.7/site-packages/boost_1_45/mpi.so * QA Notice: invalid reference to libboost_mpi_python-mt-1_45.dylib in /opt/gentoo/usr/lib/python2.7/site-packages/boost_1_45/mpi.so * QA Notice: invalid reference to libboost_python-mt-1_45.dylib in /opt/gentoo/usr/lib/python2.7/site-packages/boost_1_45/mpi.so * QA Notice: invalid reference to libboost_mpi-mt-1_45.dylib in /opt/gentoo/usr/lib/python2.7/site-packages/boost_1_45/mpi.so * QA Notice: invalid reference to libboost_serialization-mt-1_45.dylib in /opt/gentoo/usr/lib/python2.7/site-packages/boost_1_45/mpi.so * ERROR: dev-libs/boost-1.45.0 failed: * invalid install_name found, your application or library will crash at runtime This is probably related to the destdir hack of boost_build in the boost ebuild, which doesn't work in this case.
Can you test with the new 1.52 versions?