[bjam][1.41.0] Build with variant=release, debug fails
I am trying to build the Boost 1.41.0 libraries with this command: bin/bjam --user-config=user-config.LINUX_AMDF7 threading=multi instruction-set=opteron address-model=64 variant=release,debug,profile link=static,shared --stagedir=stageF7 stage The last time I built Boost libraries was version 1.35.0. I eliminated all of the other options to narrow the problem to just this option: variant=release,debug The build starts up successfully, if I select just one option for variant (debug or release), but it fails when I try to build both. These are the error messages: error: Duplicate name of actual target: <pstageF7/lib>libboost_date_time.a error: previous virtual target { common%common.copy-libboost_date_time.a.STATIC_LIB { gcc%gcc.archive-libboost_date_time.a.STATIC_LIB { gcc%gcc.compile.c++-gregorian/greg_month.o.OBJ { gregorian/greg_month.cpp.CPP } } { gcc%gcc.compile.c++-gregorian/greg_weekday.o.OBJ { gregorian/greg_weekday.cpp.CPP } } { gcc%gcc.compile.c++-gregorian/date_generators.o.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-libboost_date_time.a.STATIC_LIB { gcc%gcc.archive-libboost_date_time.a.STATIC_LIB { gcc%gcc.compile.c++-gregorian/greg_month.o.OBJ { gregorian/greg_month.cpp.CPP } } { gcc%gcc.compile.c++-gregorian/greg_weekday.o.OBJ { gregorian/greg_weekday.cpp.CPP } } { gcc%gcc.compile.c++-gregorian/date_generators.o.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: added properties: <debug-symbols>on <inlining>off <optimization>off <runtime-debugging>on <variant>debug error: removed properties: <debug-symbols>off <define>NDEBUG <inlining>full <optimization>speed <runtime-debugging>off <variant>release /netDISKS/cgi/LINUX_AMD64/cgi/vendor/library/boost/boost_1_41_0/tools/build/v2/build/virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@4821 /netDISKS/cgi/LINUX_AMD64/cgi/vendor/library/boost/boost_1_41_0/tools/build/v2/build/virtual-target.jam:135: in object(file-target)@4821.actualize from module object(file-target)@4821 /netDISKS/cgi/LINUX_AMD64/cgi/vendor/library/boost/boost_1_41_0/tools/build/v2/build-system.jam:717: in load from module build-system /netDISKS/cgi/LINUX_AMD64/cgi/vendor/library/boost/boost_1_41_0/tools/build/v2/kernel/modules.jam:283: in import from module modules /netDISKS/cgi/LINUX_AMD64/cgi/vendor/library/boost/boost_1_41_0/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module /netDISKS/cgi/LINUX_AMD64/cgi/vendor/library/boost/boost_1_41_0/boost-build.jam:17: in module scope from module The user-config contains just these 2 lines: using gcc : 4.1.2 : /usr/bin/g++ : <compileflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" <linkflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" ; using python : 2.5 : /usr ; It seems possible that the libraries would build correctly in separate steps, but I am concerned that the debug, release, and profile versions will be mixed up. Is this just a problem for the date_time library, or is there something wrong with the build rules? If someone can give me a reliable workaround, I would appreciate it. (I am building with g++ 4.1.2 on a Fedora 7 x86_64 Linux system.) -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560
Richard Hadsell wrote:
I am trying to build the Boost 1.41.0 libraries with this command:
bin/bjam --user-config=user-config.LINUX_AMDF7 threading=multi instruction-set=opteron address-model=64 variant=release,debug,profile link=static,shared --stagedir=stageF7 stage
The last time I built Boost libraries was version 1.35.0. I eliminated all of the other options to narrow the problem to just this option:
variant=release,debug
The build starts up successfully, if I select just one option for variant (debug or release), but it fails when I try to build both. These are the error messages:
error: Duplicate name of actual target: <pstageF7/lib>libboost_date_time.a
By default, the build process creates libraries named in accordance with system conventions, e.g. libboost_date_time.a -- and naturally, you cannot produce both debug and release libraries named that way. So, either build one variant or use --layout=tagged. HTH, Volodya
Vladimir Prus wrote:
By default, the build process creates libraries named in accordance with system conventions, e.g. libboost_date_time.a -- and naturally, you cannot produce both debug and release libraries named that way. So, either build one variant or use --layout=tagged.
HTH, Volodya
It does help, thanks. I decided to build one at a time, and I found that I have to give each variant a different stagedir name. Otherwise, they overwrite each other. BTW, I checked the 1.41.0 Getting Started doc for Linux and found that it is out of date in this respect. It describes the old naming convention that appends various suffixes to the library names. I then jumped via a link to Boost.build documentation. It is also out of date, not mentioning the limitation on variant, and not mentioning variant=profile, which has been around at least since 1.35.0. Again, thanks for the response. -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560
Richard Hadsell wrote:
Vladimir Prus wrote:
By default, the build process creates libraries named in accordance with system conventions, e.g. libboost_date_time.a -- and naturally, you cannot produce both debug and release libraries named that way. So, either build one variant or use --layout=tagged.
HTH, Volodya
It does help, thanks. I decided to build one at a time, and I found that I have to give each variant a different stagedir name. Otherwise, they overwrite each other.
BTW, I checked the 1.41.0 Getting Started doc for Linux and found that it is out of date in this respect.
I have an action item to fix that for 1.42
It describes the old naming convention that appends various suffixes to the library names. I then jumped via a link to Boost.build documentation. It is also out of date, not mentioning the limitation on variant,
There's no inherent limitation on variant, it's just the general limitation that you cannot install >1 variant in one place without some renaming.
and not mentioning variant=profile, which has been around at least since 1.35.0.
Well, given that it's kinda useless these days, we probably don't need to document it. - Volodya
participants (2)
-
Richard Hadsell
-
Vladimir Prus