Subject: Re: [boost] [Boost-maint] [context, config] Always setting address-model and architecture (Was: Conflicts when building libraries at root)
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-02-28 10:44:32
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Vladimir Prus
> Sent: 19 February 2015 09:10
> To: boost_at_[hidden]
> Subject: Re: [boost] [Boost-maint] [context, config] Always setting address-model and architecture
> Conflicts when building libraries at root)
> On 02/18/2015 07:10 PM, Jürgen Hunold wrote:
> >> Right, so steps would be:
> >> >
> >> >1. Move actual tests into config (we do need to have a few cpp
> >> >files) 2. Move architecture.jam into either Boost.Build or
> >> >boostcpp.jam 3. Make sure we don't generate extra path elements for
> >> >default address model 4. Introduce a way to do these tests without
> >> >requiring a bunch of .cpp files - sure Boost.Build can generate them on the fly.
> >> >5. Make these checks be automatic for all projects.
> >> >
> >> >It seems that 1-2 should solve the immediate problem, and 1-3 should
> >> >be pretty good, although going all the way to 5 would be cool.
> > +1 for this plan.
> > And it would be cool if 3 enables me to use "feature.set-default
> > address-model
> > : 64" on Windows 64 bit machines to enforce 64 bit builds as default.
> > Or maybe just auto-detect it...
> I have patches for 1-2, over at:
> You will need --without-log for them to work.
> Hiding architecture/address-model from path is not quite as easy, since that must be done per
> different toolchains can have different defaults. Or I can possibly just use "64" and "x86",
> name, in target paths.
OK chaps - all this discussion left me in a state of partial disambiguation.
But now, after a GIT corruption, I've chosen to start right from the top after deleting my entire
module-boost directory, and reinstalling everything from scratch.
I'm working on branch develop and trying to build all the libraries, as per
And I'm stuck at this point again.
What do I do to get over this for now?
Install the patch mentioned https://gist.github.com/vprus/6017091aef8126919980
Try to build with these options?
(actually I'm on Windows 8.1 64-bit, so what should I specify ?
I:\modular-boost>.\b2 --address-model=64 > ../develop-build.log doesn't work :-(
I:\modular-boost>.\b2 --address-model=32 > ../develop-build.log doesn't work either :-((
Suggestions please - I'm stuck.
PS (supplementary: Will I potentially need both 32 and 64 bit libraries?)
Building the Boost C++ Libraries.
Performing configuration checks
- symlinks supported : yes
- 32-bit : yes
- arm : no
- mips1 : no
- power : no
- sparc : no
- x86 : yes
- has_icu builds : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add "using mpi ;" to your user-config.jam
- zlib : no
- iconv (libc) : no
- iconv (separate) : no
- icu : no
- icu (lib64) : no
- message-compiler : yes
- compiler-supports-ssse3 : yes
- compiler-supports-avx2 : yes
- gcc visibility : no
- long double support : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.
warning: No python installation configured and autoconfiguration
note: failed. See http://www.boost.org/libs/python/doc/building.html
note: for configuration instructions or pass --without-python to
note: suppress this message and silently skip all Boost.Python targets
- zlib : no (cached)
error: Name clash for '<pstage\lib>libboost_system-vc120-mt-1_58.lib'
error: Tried to build the target twice, with property sets having
error: these incompabile properties:
error: - none
error: - <address-model>32 <architecture>x86
error: Please make sure to have consistent requirements for these
error: properties everywhere in your project, especially for install
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk