Having discovered the profile variant (maybe it's new with 1.34.0), I tried to build all 3 variants that I want and stage them to a common directory. Unfortunately, the profile variant doesn't add its own suffix to the output library, the way the debug version does. The profiling library has the same name as the optimized (release) version. I figured that I could workaround the problem by putting the profile variant into its own stage directory, but that is not what I really want. This is what happened with the current 1.34.0 beta build: 810% bjam --user-config=user-config.LINUX_AMDFC3 threading=multi instruction-set=opteron address-model=64 cxxflags=-fPIC variant=release,debug,profile --stagedir=stageFC3 stage Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). <...>/boost_1_34_0_beta/tools/build/v2/build/virtual-target.jam:996: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstageFC3/lib>libboost_date_time-gcc34-mt-1_34.so.1.34.0 error: previous virtual target { common%common.copy-libboost_date_time-gcc34-mt-1_34.so.1.34.0.SHARED_LIB { gcc%gcc.link.dll-libboost_date_time-gcc34-mt-1_34.so.1.34.0.SHARED_LIB { gcc%gcc.compile.c++-greg_month.o.OBJ { gregorian/greg_month.cpp.CPP } } { gcc%gcc.compile.c++-greg_weekday.o.OBJ { gregorian/greg_weekday.cpp.CPP } } { gcc%gcc.compile.c++-date_generators.o.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-libboost_date_time-gcc34-mt-1_34.so.1.34.0.SHARED_LIB { gcc%gcc.link.dll-libboost_date_time-gcc34-mt-1_34.so.1.34.0.SHARED_LIB { gcc%gcc.compile.c++-greg_month.o.OBJ { gregorian/greg_month.cpp.CPP } } { gcc%gcc.compile.c++-greg_weekday.o.OBJ { gregorian/greg_weekday.cpp.CPP } } { gcc%gcc.compile.c++-date_generators.o.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: added properties: <debug-symbols>on <profiling>on <variant>profile error: removed properties: <debug-symbols>off <profiling>off <variant>release <...>/boost_1_34_0_beta/tools/build/v2/build/virtual-target.jam:459: in actualize-no-scanner from module object(file-target)@4418 <...>/boost_1_34_0_beta/tools/build/v2/build/virtual-target.jam:111: in object(file-target)@4418.actualize from module object(file-target)@4418 <...>/boost_1_34_0_beta/tools/build/v2/build-system.jam:476: in load from module build-system <...>/boost_1_34_0_beta/tools/build/v2/kernel/modules.jam:261: in import from module modules <...>/boost_1_34_0_beta/tools/build/v2/kernel/bootstrap.jam:132: in boost-build from module <...>/boost_1_34_0_beta/boost-build.jam:9: in module scope from module The messages provided enough info to show that the conflict was between release and profile variants. I came up with a fix that you developers might like to consider. I added a line to common.jam to give the profile variant a "runtime-tag". Of course, 'p' is the appropriate tag, but stlport has already used 'p' for itself. I don't know why anyone would want to build both with and without stlport, but I certainly don't, so the conflict doesn't bother me. But you might change it to something like 'sp'. The resulting diff: diff -u -r1.1.1.1 common.jam --- tools/build/v2/tools/common.jam 27 Apr 2007 17:12:56 -0000 1.1.1.1 +++ tools/build/v2/tools/common.jam 1 May 2007 17:04:37 -0000 @@ -792,7 +792,8 @@ if <python-debugging>on in $(properties) { tag += y ; } if <variant>debug in $(properties) { tag += d ; } - if <stdlib>stlport in $(properties) { tag += p ; } + if <variant>profile in $(properties) { tag += p ; } + if <stdlib>stlport in $(properties) { tag += sp ; } if <stdlib-stlport:iostream>hostios in $(properties) { tag += n ; } return $(tag:J=) ; -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601